Return-Path: Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: (qmail 28212 invoked from network); 12 Aug 2009 03:27:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 12 Aug 2009 03:27:32 -0000 Received: (qmail 41239 invoked by uid 500); 12 Aug 2009 03:27:38 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 41192 invoked by uid 500); 12 Aug 2009 03:27:38 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 41117 invoked by uid 99); 12 Aug 2009 03:27:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Aug 2009 03:27:21 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=FM_FAKE_HELO_VERIZON,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [206.46.173.1] (HELO vms173001pub.verizon.net) (206.46.173.1) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Aug 2009 03:27:10 +0000 Received: from [192.168.1.43] ([72.93.194.99]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KO8005B6UVHLEJ4@vms173001.mailsrvcs.net> for dev@cxf.apache.org; Tue, 11 Aug 2009 22:26:06 -0500 (CDT) Message-id: <4A82364D.5030405@ece.neu.edu> Date: Tue, 11 Aug 2009 23:26:05 -0400 From: Demetris User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-version: 1.0 To: dev@cxf.apache.org Subject: Re: WSDL2JS References: <4A8067CA.60009@ece.neu.edu> <61b5d9410908110437r4c4c35eblce64661d12eaedf5@mail.gmail.com> <4A81992C.1060708@ece.neu.edu> <200908111250.53046.dkulp@apache.org> <4A81D2CA.7050003@ece.neu.edu> <61b5d9410908111813p79fb2967tcc63ac54b850a6a5@mail.gmail.com> In-reply-to: <61b5d9410908111813p79fb2967tcc63ac54b850a6a5@mail.gmail.com> Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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. 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 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 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 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 >>>>>>>>>> >>>>>>>>>> >>> 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 >>>>>>>>>>> >>>>>>>>>>> >>> > >