On Tue August 11 2009 11:26:05 pm Demetris wrote: > Do you know if Axis 1.x can generate document/literal or only > rpc/encoded? I am wondering if setting > the OPERATION_STYLE_PROPERTY to document would do the trick.
I believe Axis1 can do doc/literal. JAX-RPC did require some level of support for that so I'm pretty sure Axis1 implemented it. Not sure how to go about configuring it to do so. I'm not an Axis1 user. :-) Dan > Benson Margulies wrote: > > Demetris, > > > > If your place has a big investment in RPC/encoded, perhaps one of you > > would like to pick up the project that one of our committers started > > of adding RPC/encoded support to CXF. If you do it, you get to ensure > > that it works with your services :-). I'd be happy to mentor someone > > in figuring out where Dain left off. > > > > --benson > > > > On Tue, Aug 11, 2009 at 4:21 PM, Demetris<demet...@ece.neu.edu> wrote: > >> Of course I do see infrastructures here in production still using Axis > >> 1.x without any plans on > >> migrating while other systems come into play with Axis 2 etc. and > >> interoperability between the > >> two sides is impossible - and of course the rest of us will need to sit > >> in between and needing to > >> do our own translations - not good. > >> In any case, CFX is a pretty impressive project so I have a feeling I > >> will be adapting it to my > >> work. > >> > >> Cheers > >> > >> Daniel Kulp wrote: > >>> On Tue August 11 2009 12:15:40 pm Demetris wrote: > >>>> That's what I figured ;) Thanks for the info Benson. > >>>> > >>>> Now regarding inteconnection of Web Services across implementations, > >>>> if there is no bridge > >>>> between the old RPC/encoded and CFX, at least I am assuming that newer > >>>> versions would > >>>> be able to handle SOAP calls across them or not? This is something I > >>>> never tried/looked into > >>>> while I worked exclusively with Axis so I was wondering. > >>> > >>> Pretty much none of the modern SOAP toolkits support RPC/encoded. > >>> Axis2 doesn't. CXF doesn't. Metro/JAX-WS RI doesn't. Etc.... > >>> Basically, rpc/encoded was such an interopability nightmare that it > >>> really fell into the bucket of "You REALLY REALLY don't want to use > >>> it." If you want interopability, you really need to migrate to one > >>> of the literal forms. > >>> > >>> Dan > >>> > >>>> Benson Margulies wrote: > >>>>> OK, that message is buried in the substrate somewhere. I'm not sure > >>>>> that I agree with it :-) In practical terms, we just don't have the > >>>>> code or RPC/encoded. > >>>>> > >>>>> I'm unaware of anything you can use to interconnect an old Axis > >>>>> RPC/encoded service with CXF. > >>>>> > >>>>> On Mon, Aug 10, 2009 at 11:00 PM, Demetris<demet...@ece.neu.edu> wrote: > >>>>>> Hi Benson, > >>>>>> > >>>>>> the reason I mentioned JAX-WS is because a WSDL file that I passed > >>>>>> to WSDL2JS returned > >>>>>> "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it > >>>>>> is "neither here nor > >>>>>> there" but I wanted to double-check - I think I know what the issue > >>>>>> is now after reading the > >>>>>> corresponding documentation but I will return and send more info if > >>>>>> I cannot resolve it. > >>>>>> > >>>>>> A separate question - is there a "bridge" between Axis WS and its > >>>>>> tools and CFX? Can an Axis > >>>>>> WS client call a CFX-implemented WS and vice versa or not? > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>> Benson Margulies wrote: > >>>>>>> Demetris, > >>>>>>> > >>>>>>> CXF includes the ability to build Soap 1.1 Javascript clients for > >>>>>>> doc/lit and rpc/lit services. JAX-WS is relatively neither here nor > >>>>>>> there. > >>>>>>> > >>>>>>> The code can be run in two modes. You can run the tool as a > >>>>>>> standalone, and you get Javascript that (with the utility file > >>>>>>> supplied) will run anywhere that has a compatible request object. > >>>>>>> Or, you can ask any CXF-implemented web service to deliver a > >>>>>>> javascript client, and one will be returned. > >>>>>>> > >>>>>>> Have you read > >>>>>>> http://cwiki.apache.org/CXF20DOC/javascript-clients.html? > >>>>>>> > >>>>>>> --benson > >>>>>>> > >>>>>>> On Mon, Aug 10, 2009 at 5:40 PM, Demetris<demet...@ece.neu.edu> wrote: > >>>>>>>> And one more observation - because wsdl2js utilizes JAX-WS 2.0, > >>>>>>>> RPC/Encoded > >>>>>>>> documents are not supported. Is that correct? > >>>>>>>> > >>>>>>>> Thanks again > >>>>>>>> > >>>>>>>> Demetris wrote: > >>>>>>>>> Ok now that I played a bit with wsdl2js I am beginning to > >>>>>>>>> understand what > >>>>>>>>> you said below. > >>>>>>>>> So one can use the wsdlurl in order to get the server to return > >>>>>>>>> the script > >>>>>>>>> - can you please > >>>>>>>>> clarify a few things since I am new to this - > >>>>>>>>> 1. what kind of server are we talking about in this case? > >>>>>>>>> 2. The only way to generate the Javascript is through a remote > >>>>>>>>> server > >>>>>>>>> + URL? If I have the WSDL > >>>>>>>>> in my possesion how can I use this tool to generate the script of > >>>>>>>>> me? > >>>>>>>>> > >>>>>>>>> Thanks again > >>>>>>>>> > >>>>>>>>> Benson Margulies wrote: > >>>>>>>>>> The tool is part of CXF, so it requires Java 1.5. Since its > >>>>>>>>>> output is Javascript, I don't understand why you need to run it > >>>>>>>>>> under J2ME. > >>>>>>>>>> In fact, you can just use the ?js URL form from the server to > >>>>>>>>>> get the server to generate it on the fly. > >>>>>>>>>> > >>>>>>>>>> On Mon, Aug 10, 2009 at 2:32 PM, Demetris<demet...@ece.neu.edu> > >>> > >>> wrote: > >>>>>>>>>>> Hi all, > >>>>>>>>>>> > >>>>>>>>>>> I am interested in generating Javascript stubs from a WSDL > >>>>>>>>>>> file - I am > >>>>>>>>>>> assuming that the WSDL2js tool is the > >>>>>>>>>>> appropriate tool to use. Has anyone used this tool so that I > >>>>>>>>>>> can ask a couple of Qs? > >>>>>>>>>>> > >>>>>>>>>>> (1) Which Java version is the tool built on? > >>>>>>>>>>> (2) Can I used it under J2ME-CDC to generate stubs for mobile > >>>>>>>>>>> devices? > >>>>>>>>>>> > >>>>>>>>>>> Thanks in advanced -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
