Right now, the code generation maps from the CXF abstract service model to Javascript using entirely hand-coded methods. I have this suspicion that little or none of what you need for JAX-RS is in the service model. Dan and I had a discussion of a more generic annotation model. I wanted it to allow some customization of Javascript generation via some annotations. You might find that that it allowed all those JAX-RS snails to be represented in the service model. This is all on the line of trying to make a relatively monolithic Javascript generator handle both flavors of JAX.
The other direction would be, as you write, to use JAX-RS's existing data structure to drive the generation of JavaScript, and then to see how you could set up code sharing with the SOAP generation code I wrote. If you read the code gen code, you might throw up. Or you might observe some pieces that look like they could be reused. Right now, I don't think I have enough neurons left after real-job, XmlSchema, and real life to take something like this on. However, I can answer any questions you have about the code and make suggestions if you head down one path or another. On Tue, Dec 2, 2008 at 5:48 AM, Sergey Beryozkin <[EMAIL PROTECTED]> wrote: > Hi Benson > > I was wondering, how realistic could it be to have some of the code in a > frontend/javascript reused to have a client java script code generated which > will be able to invoke on a JAXRS service ? > > I reckon it would be up to a custom JAXRS RequestHandler (which has an access > to a JAXRS resource class and subresources) to introspect a resource class > and respond with a JavaScript code to be run, say, in a browser. Matching a > corresponding capability of SOAP-based services is the goal. > > Or would it be easier if some form of imtermediate description were available > to a java script code generator ? > > Thanks, Sergey
