cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mao <james....@iona.com>
Subject Re: tools for javascript
Date Tue, 04 Dec 2007 02:57:32 GMT

> This thing generates javascript clients. It works with the existing
> frontends. All the generation code exists already in rt/javascript. We
> could, I suppose, have a different generator for the pre-existing
> javascript front end, to assist people in writting JavaScript \servers/.
> My brain hurts in terms of how we name these things distinctly, since
> they have pretty nearly nothing to do with each other.
>   

I know, I just saw your another mail.

But I'm still thinking the whole layout of the package, I'm thinking of 
a new frontend for tools (e.g tools-js-frontend)
All the code gen related to the js, should go into the js frontend. and 
the frontend can call the rt/js  which you already done.
The wsdlto/core has a spec as well, which allows to load the frontend, 
in verbose mode, it will print
"Loading JaxWs frontend"
Which in JS case, should load the
"Loading JS frontend"

Make sense?
> Right now, if you have a service running against the trunk code, you can
> push in a URL like:
>
> http://host:port/Service?js
>
> and get back a JavaScript client. The momentary goal is to have the
> ability to do the same thing from command-line (or maven). 
>   

Right, I understand that

> So, it really is like wsdl generation except that it generates a
> different artifact.
>
> It also makes sense to have a wsdl2js command, by the same logic.
>   

Exactly, make no sense to re-invent the wheel :)

James
>
>
>   
>> -----Original Message-----
>> From: James Mao [mailto:james.mao@iona.com] 
>> Sent: Monday, December 03, 2007 9:42 PM
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: tools for javascript
>>
>> WsdlTo actually is a framework, we have frontend plugin and 
>> databinding plugin, we only have jaxws and jaxb for each,
>>
>> The wsdl2js, I guess it's a js frontend, right?, so we can 
>> make it as a plugin as well, and which databinding are you 
>> using? jaxb, or aegis?
>>
>> The artifacts that you are going to generate can be defined 
>> as a Velocity template
>>
>> All in all, wsdl2java will load wsdl file -> build wsdl4j 
>> definition model -> [validation] -> [customization] -> build 
>> service model -> validation -> cxf java model -> generators 
>> -> artifacts, That's how it works
>>
>> JavaTo is a little bit different,
>>
>> We support both simple frontend and jaxws frontend,  we will 
>> try to detect the frontend from the class you provide, then 
>> we reused the rt/core, to build the service from the java 
>> class, then we use the Service2Wsdl builder to build the 
>> wsdl, of course, now we not just generate the wsdl, we 
>> generate other stuff as well, like the wrapper bean classes etc.
>>
>> For the CLI, we used the code donated from IONA, which called 
>> xsume, it use the xml file to define the arguments/options etc.
>>
>> I would like to hear from you, about the plan, is it target 
>> to cxf 2.1? 
>> or later
>>
>> I'm working on jaxws 2.1 stuff at moment, so probably will 
>> not involve that much before 2.1, but i would like someone 
>> can try the tools framework, That would very helpful to make 
>> the api more flexible
>>
>> Regards,
>> James
>>
>>
>>     
>>> It is time to create wsdl2js and java2js. I confess that I 
>>>       
>> am daunted 
>>     
>>> by the task of starting this from zero. Is there any 
>>>       
>> possibilies that 
>>     
>>> the tool-experts would be willing to create some shells for me?
>>>
>>>
>>>   
>>>       
>>     
>
>
>   


Mime
View raw message