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 03:31:14 GMT
Forget about the frontend, there's only one module in the tools/javato 
at moment, (The frontend I mentioned previously was for the tools/wsdlto)

My suggestion here is to have scripts for the java2js, and put the js 
stuff inside the java2ws.

James

> Jim and James,
>
> I agreed with James, and now I want to agree with Jim.
>
> The problem with calling Javascript a front end is that we then need two
> front ends at the same time.
>
> To generate JS from Java, we need to specify:
>
>  ... JAXWS or Simple (and their options)
>  ... JAXB or Aegis (or one of the more exotic others) (and their
> options)
>  ... the SEI
>  ... the classpath
>
> Given these items, we can construct a service model. Given a service
> model, we can generate a client in JavaScript.
>
> We can't make JS a third choice from JAXWS and Simple, because we need
> to use of of them.
>
> Sadly, I'm really exhausted. I'm going to go away, and look forward to
> reading the results of your further deliberations when I get up in the
> morning.
>
> Hiding in the background is the existing support for Javascript
> \servers/. Hypothetically, we could even have js2js. I propose to
> completely ignore this issue for the moment.
>
>
> --benson
>
>
>
>   
>> -----Original Message-----
>> From: Jim Ma [mailto:ema@iona.com] 
>> Sent: Monday, December 03, 2007 10:07 PM
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: tools for javascript
>>
>>
>>  Benson Margulies wrote:
>>     
>>> Here is the XML for the java2js command.
>>>
>>> The basic idea is this: the code has to process a service. 
>>>       
>> That means 
>>     
>>> it needs an SEI, a front-end, and a data binding, just like 
>>>       
>> java2ws. 
>>     
>>> This is going to require some refactoring of code into some common 
>>> place from java2ws. It can't be tools-common, without producing a 
>>> circular build-path problem. The whole idea of the 
>>>       
>> implementation of 
>>     
>>> rt/javascript is that this tool is very nearly identical to 
>>>       
>> java2ws. 
>>     
>>> We want to cause the very same kind of ServiceInfo model to 
>>>       
>> get built, 
>>     
>>> but then run a Javascript generator instead of a WSDL generator.
>>>   
>>>       
>> Agreed !
>> I can split java2ws  into two modules : java2common and 
>> java2ws  then you can reuse the java2common to build this new tool .
>>
>>
>>     
>
>
>   


Mime
View raw message