Re: VOTE: Extend CXF to support JAX-RPC - Good work

[Benson Margulies <bi...@gmail.com>]

Karthik,

Once upon a time, we had an active contributor to CXF who was working
toward JAX-RPC support. He wrote code to support SOAP-encoded
representation in the Aegis data binding. Sadly, he got too busy with
his real job, and never finished.

There is no plan to work on this. If someone comes to the project who
wants to do it, they will get support and encouragement, but I do not
believe that any of the current contributors have any plans.

--benson


On Thu, Feb 11, 2010 at 2:10 AM, Karthik K <ka...@gmail.com> wrote:
> Hi
>
> This is realted to your development metioned in one of the forum. I found
> the its required that CXF supports JAX-RPC as many system is still not
> migrated to JAX-WS and we may required to build atleast a click to our
> legacy systems via CXF.
>
> Kindly confirm me which release of CXF is supporting JAX-RPC. If you can
> pass me an example that would be great.
>
> Thanks and Regards
> Karthik

Re: VOTE: Extend CXF to support JAX-RPC - Good work

[Benson Margulies <bi...@gmail.com>]

Well, we certainly supported and encouraged Dain when he did a good dea of it.

On Fri, Feb 12, 2010 at 5:18 AM, Glen Mazza <gl...@gmail.com> wrote:
>
> Hmm, I'm not sure at this late date if anyone wanted to burden the CXF
> project with that old JAX-RPC stuff they would indeed get "support and
> encouragement".  Who would want to maintain and support that?  Unless there
> is a paid need from one of CXF's sponsors for such functionality, there are
> legacy products (XFire, Axis1, Sun's JWSDP) that can be used for solve
> legacy problems such as these without needing to weigh down CXF with
> yesterday's technology.  JAX-WS Dispatch can also be used within CXF for
> JAX-RPC calls.
>
> Glen
>
>
> bimargulies wrote:
>>
>> Karthik,
>>
>> Once upon a time, we had an active contributor to CXF who was working
>> toward JAX-RPC support. He wrote code to support SOAP-encoded
>> representation in the Aegis data binding. Sadly, he got too busy with
>> his real job, and never finished.
>>
>> There is no plan to work on this. If someone comes to the project who
>> wants to do it, they will get support and encouragement, but I do not
>> believe that any of the current contributors have any plans.
>>
>> --benson
>>
>>
>> On Thu, Feb 11, 2010 at 2:10 AM, Karthik K <ka...@gmail.com> wrote:
>>> Hi
>>>
>>> This is realted to your development metioned in one of the forum. I found
>>> the its required that CXF supports JAX-RPC as many system is still not
>>> migrated to JAX-WS and we may required to build atleast a click to our
>>> legacy systems via CXF.
>>>
>>> Kindly confirm me which release of CXF is supporting JAX-RPC. If you can
>>> pass me an example that would be great.
>>>
>>> Thanks and Regards
>>> Karthik
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Re%3A-VOTE%3A-Extend-CXF-to-support-JAX-RPC---Good-work-tp27547385p27561396.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>

Re: VOTE: Extend CXF to support JAX-RPC - Good work

[kdesin <ka...@gmail.com>]

Hi all,

I deeply wish that there is support for JAX-RPC from the current
implementation of CXF:

I am in a situation where I need to consume a JAX-RPC webservice using
JAX-WS support.

I know that migrating to JAX-WS entirely is the best option but due to some
vendor issues we cannot do that.

I have come across the Dispatch API in JAX-WS to achieve this.(Our services
layer runs on CXF so I am forced to go via this route)

All I am trying is to write a standalone client to invoke the RPC service
and display the output.

Please let me know how to resolve this error:

Service service = Service.create(url, SERVICE);
 javax.xml.ws.Dispatch dispatch =
service.createDispatch(GatewaySoapPort,javax.xml.transform.Source.class,
Service.Mode.PAYLOAD); Source req = new StreamSource("rpc.xml"); 
Source res = dispatch.invoke(req); /*Error at this point*/

Exception:

Exception in thread "main" javax.xml.ws.WebServiceException:
java.lang.IllegalStateException: Current event not START_ELEMENT or
END_ELEMENT at
com.sun.xml.ws.encoding.soap.client.SOAPXMLDecoder.toInternalMessage(SOAPXMLDecoder.java:263)
at
com.sun.xml.ws.protocol.soap.client.SOAPMessageDispatcher.receive(SOAPMessageDispatcher.java:545)
at
com.sun.xml.ws.protocol.soap.client.SOAPMessageDispatcher.doSend(SOAPMessageDispatcher.java:288)
at
com.sun.xml.ws.protocol.soap.client.SOAPMessageDispatcher.send(SOAPMessageDispatcher.java:153)
at
com.sun.xml.ws.client.dispatch.impl.DispatchDelegate.send(DispatchDelegate.java:71)
at
com.sun.xml.ws.client.dispatch.DispatchBase.sendAndReceive(DispatchBase.java:308)
at com.sun.xml.ws.client.dispatch.DispatchBase.invoke(DispatchBase.java:133)

-----
Saludos
Kartheek
--
View this message in context: http://cxf.547215.n5.nabble.com/Re-VOTE-Extend-CXF-to-support-JAX-RPC-Good-work-tp547563p5710671.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: VOTE: Extend CXF to support JAX-RPC - Good work

[Daniel Kulp <dk...@apache.org>]

On Fri February 12 2010 5:18:20 am Glen Mazza wrote:
> Hmm, I'm not sure at this late date if anyone wanted to burden the CXF
> project with that old JAX-RPC stuff they would indeed get "support and
> encouragement".  

Well, I disagree.   If someone would find it useful (and there are enough 
legacy applications that could be more easily upgraded) AND they were willing 
to work on it and support it, I see no issues with it.   I know several of 
IONA/Progress customers expressed some interest, but not enough interest to 
cost justify the work on our end.   In general, we encouraged customers to 
migrate full over to JAX-WS.


> Who would want to maintain and support that?   

Well, I'd hope that by the time they got JAX-RPC working, they'd be a 
committer and they could help maintain it.  :-)

Seriously, I would definitely not mind it.   I don't think I'd bother with 
tooling for it (wsdl2java type stuff), but to help migrate existing 
applications to a modern stack, it could be quite useful.   XFire didn't 
support JAX-RPC.   Really, the only (open source) choices are Axis1 and the 
Sun reference implementation.  (JBoss has an implementation as well, but it's 
kind of tied to JBoss)   Both those implementations are quite slow, buggy, 
unsupported, and certainly cannot be updated to support some of the new 
features such as WS-SecurityPolicy and such.   If someone wanted to add 
security support to an existing JAX-RPC application, it's definitely not easy.  

That all said, while I would definitely support and encourage anyone that 
would like to work on it, (heck, I'll probably add it to the idea list for 
Google summer of code this year)   it's not something I would have the time to 
work on myself unless a paying customer really demanded it.   

Dan



> Unless there
> is a paid need from one of CXF's sponsors for such functionality, there are
> legacy products (XFire, Axis1, Sun's JWSDP) that can be used for solve
> legacy problems such as these without needing to weigh down CXF with
> yesterday's technology.  JAX-WS Dispatch can also be used within CXF for
> JAX-RPC calls.
> 
> Glen
> 
> bimargulies wrote:
> > Karthik,
> > 
> > Once upon a time, we had an active contributor to CXF who was working
> > toward JAX-RPC support. He wrote code to support SOAP-encoded
> > representation in the Aegis data binding. Sadly, he got too busy with
> > his real job, and never finished.
> > 
> > There is no plan to work on this. If someone comes to the project who
> > wants to do it, they will get support and encouragement, but I do not
> > believe that any of the current contributors have any plans.
> > 
> > --benson
> > 
> > On Thu, Feb 11, 2010 at 2:10 AM, Karthik K <ka...@gmail.com> wrote:
> >> Hi
> >> 
> >> This is realted to your development metioned in one of the forum. I
> >> found the its required that CXF supports JAX-RPC as many system is
> >> still not migrated to JAX-WS and we may required to build atleast a
> >> click to our legacy systems via CXF.
> >> 
> >> Kindly confirm me which release of CXF is supporting JAX-RPC. If you can
> >> pass me an example that would be great.
> >> 
> >> Thanks and Regards
> >> Karthik

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Re: VOTE: Extend CXF to support JAX-RPC - Good work

[Glen Mazza <gl...@gmail.com>]

Hmm, I'm not sure at this late date if anyone wanted to burden the CXF
project with that old JAX-RPC stuff they would indeed get "support and
encouragement".  Who would want to maintain and support that?  Unless there
is a paid need from one of CXF's sponsors for such functionality, there are
legacy products (XFire, Axis1, Sun's JWSDP) that can be used for solve
legacy problems such as these without needing to weigh down CXF with
yesterday's technology.  JAX-WS Dispatch can also be used within CXF for
JAX-RPC calls.

Glen


bimargulies wrote:
> 
> Karthik,
> 
> Once upon a time, we had an active contributor to CXF who was working
> toward JAX-RPC support. He wrote code to support SOAP-encoded
> representation in the Aegis data binding. Sadly, he got too busy with
> his real job, and never finished.
> 
> There is no plan to work on this. If someone comes to the project who
> wants to do it, they will get support and encouragement, but I do not
> believe that any of the current contributors have any plans.
> 
> --benson
> 
> 
> On Thu, Feb 11, 2010 at 2:10 AM, Karthik K <ka...@gmail.com> wrote:
>> Hi
>>
>> This is realted to your development metioned in one of the forum. I found
>> the its required that CXF supports JAX-RPC as many system is still not
>> migrated to JAX-WS and we may required to build atleast a click to our
>> legacy systems via CXF.
>>
>> Kindly confirm me which release of CXF is supporting JAX-RPC. If you can
>> pass me an example that would be great.
>>
>> Thanks and Regards
>> Karthik
> 
> 

-- 
View this message in context: http://old.nabble.com/Re%3A-VOTE%3A-Extend-CXF-to-support-JAX-RPC---Good-work-tp27547385p27561396.html
Sent from the cxf-user mailing list archive at Nabble.com.