cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Demetris <>
Subject Re: WSDL2JS
Date Tue, 01 Sep 2009 21:02:52 GMT

I guess no replies to the previous email below means I am on my own ...

At least one more Q:
How convoluted would it be for me at least to isolate tools like the 
wsdl2js and their classes (WSDLToJavascript etc.)
and port it into J2ME-CDC or CLDC? I guess primarily the tools 
cxf,common, and a few other
classes would be involved but other than that I can find a clean 
separation between them and the main baseline.
Any ideas?

Thanks again

Demetris wrote:
> Hi Benson et. al.,
>    I tried running the D-OSGi in Equinox under J2ME CDC on a Nokia 
> N800 but it failed (I downloaded
> and activated the single-bungle distro). So I have a feeling I will 
> have the same luck running the CXF
> stack on that mobile.  But I will give the WSDL2JS tool a shot as 
> standalone and run it on a WSDL file
> that I can generate off the mobile either on a CXF or Axis enabled 
> servers on a hoping that would work.
> Before I do I am wondering the following -
>      I will have the client mobile generate the javascript code that I 
> can execute via its browser to generate
> SOAP calls to the remote server mobile running a ksoap2 web service. 
> My questions are, has anyone tried
> to invoke Axis or any other SOAP-server-engine services from a CXF 
> client (let's say the client is executing
> the javascript generated from the server's WSDL)? Or do the SOAP 
> messages generated by CXF is annotated
> in such a way that only its server-side can understand? All this of 
> course provided the client stack can run on the
> mobile- I am working on testing that now.
> Thanks
> Benson Margulies wrote:
>> Demetris,
>> Let me answer/clarify what I can.
>> There are two ways of getting Javascript:
>> 1: ask the server to generate it via the ?js URL.
>> 2: run the generator yourself, either via the command-line driver or
>> the API it calls.
>> Both of this works either code-first or contract first. That is, you
>> start from Java classes with @nnotations, you can directly generate
>> javascript. You don't have to make a wsdl at any point.
>> You could do #2 on the client. However, I am ignorant of the
>> constraints of J2ME or CLDC, so I can't tell you if you can fit the
>> necessary set of our code onto there.
>> --benson
>> On Wed, Aug 19, 2009 at 4:41 PM, Demetris<> wrote:
>>> Hi Benson.
>>> do you mind if I ask for some clarification?
>>>> 1) you can ask the server to generate and deliver the javascript 
>>>> client.
>>> The server will actually generate and send a javascript client to the
>>> requesting remote class correct?
>>> But if need be, can the server also generate a WSDL file - which I am
>>> assuming can be used on
>>> the client side with the WSDL2js to generate the javascript client?
>>>> 2) you can create a 'dynamic client' that can talk to moderately
>>>> complex services.
>>>> However, option 2 requires the entire CXF stack on the client, and I
>>>> have no idea if J2ME has the necessary goodies.
>>> But still there is a reduced set of CXF classes that can be run under
>>> J2ME-CDC or CLDC? I am
>>> looking for the appropriate server/container that I can run under 
>>> J2ME and
>>> which can host CXF
>>> web services and I am not having much luck. I think my only option 
>>> would be
>>> to use OSGi (I think
>>> Equinox and Knopflerfish can run under J2ME) in which case I will 
>>> need a
>>> bundle-fied version of
>>> CXF - I am going over the Distributed OSGi pages on the CXF site 
>>> hoping that
>>> is what I am looking
>>> for.
>>> Thanks again

View raw message