Hi all, Our requirement to use a JAVA POJO comes from Apache Tuscany. We did a elaborate study of the different web services applications available and found Apache Tuscany to be the most easy to use and extendable software for our cause. Tuscany is based on a Service Component Architecture. It supports java and a few other languages.
Even if we directly use Etch IDL or the output of the XML binding, I think we will need some kind of middle layer to expose as SOAP. Since, the Apache Etch compiler is already able to generate Java POJOs, exposing these Java APIs as SOAP through Tuscany is very straightforward for us. As mentioned earlier, Tuscany uses Axis 2 for SOAP which internally uses JAXB. Due to these XML serializations that take place in a the web services world, we are not able to do away with the requirement for no-arg default constructors. It will be very helpful for us if we can have a compile option to add no-arg default constructors to the generated POJOs. Thanks, Nithya -----Original Message----- From: James Dixson (jadixson) Sent: Tuesday, January 20, 2009 2:01 PM To: [email protected] Subject: Re: Post to Etch developer community Nithya, Maybe if we understood better why your particular requirement forces you to start from the generated code rather than the Etch IDL? I think Niclas has point, if you were to instead start with the Etch IDL and perhaps the compiler-core code in Etch, you should be able to divine all the necessary meta information about the interface to expose via SOAP in a proxy. Another alternative to the Etch IDL would be to use the Etch compiler to generate an XML description using the XML-binding. ... There is probably no harm in generating a no-arg constructor, but it does seem a little like putting an appendix back into the patient. I should be straightforward to generate a patch on the Etch source to add the constructor to the generated Java code. However, I would not feel comfortable adding such a change into trunk until I understand the need a bit more. Or at least understanding why the Etch IDL or the XML compiler output cannot solve the problem. -- James On 1/20/09 1:07 PM, "J.D. Liau (jliau)" <[email protected]> wrote: > I think there is going to be discussions around how Etch service > exposes interfaces such as SOAP, or JavaScript, etc. Native transport > or proxy service are all very interesting ideas. > > From Etch's perspective, there is no obvious reason to add no-arg > default constructor. However, for developers who try to integrate > Etch into their existing environment and requirements, developers may > run into the same issue as Nithya and would like to modify compiler > generated code. > > So, what's the downside having new Etch compiler option to generate > no-arg default constructor (or similar change) on demand? It does not > change the integrity of Etch runtime and it is not default Etch > compiler option but you give developers other possibilities for further > integration. > > -----Original Message----- > From: [email protected] [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of Niclas > Hedhman > Sent: Tuesday, January 20, 2009 9:40 AM > To: [email protected] > Subject: Re: Post to Etch developer community > > Hi, > Cake-on-Cake is an expression in Sweden, when you talk about > unnecessary layering. > > To me, and I am by no means an expert but would like to take a shot at > this, the approach is wrong. IIUIC, you are introducing an extra SOAP > tier for no particular reason, other than having the service available > via SOAP, in which case you might as well do the decorators by > yourself or a dynamic proxy. OTOH, Etch IDL should be used as the > source to generate the SOAP interface straight at the service, and > possibly Etch could later introduce proxy services which could be > utilized for 'extra tier' requirements. Sticking SOAP on the Java > generated client sounds like an typical anti-pattern to me. > > Cheers > Niclas > > On Sat, Jan 17, 2009 at 2:17 AM, Nithya Vijayakumar (nvijayak) > <[email protected]> wrote: >> Etch Developers, >> >> Our current posting is to request no-arg default constructor in all >> generated Etch java sources. >> >> We are using Apache Etch for our services. We have a requirement to >> expose Etch as a SOAP web service. We are using the open source >> Apache > >> software Tuscany 1.3 and Axis 2 for this purpose. While integrating >> we found that the java source code created by the Etch Compiler >> cannot > >> be exposed as a SOAP service as it currently does not have a no-arg >> default constructor. The requirement stems from Apache Axis 2 and >> its > >> use of JAXB for data binding. >> >> Apache Axis 2 is our underlying SOAP provider. This dictates for a >> no-arg default constructor for even things like WSDL generation. >> Further when we would like to serialize objects to XML using >> libraries > >> like Xstream/JAXB, which in turn try to construct objects before >> serializing them to XML using the default constructor. Even when >> services are exposed as SOAP via just Apache AXIS (stand alone), >> there > >> is a need for a default constructor. We ran some examples that ship >> with Axis 2 and removed the no-arg constructors for complex objects >> and the service didn't deploy. >> >> We are adding some references to this topic. We hope the Etch >> developer community would be quick to respond to this issue. >> >> http://www.mail-archive.com/[email protected]/msg00951.html <http://www.mail-archive.com/[email protected]/msg00951.html> >> >> http://ws.apache.org/axis2/1_4_1/jaxws-guide.html <http://ws.apache.org/axis2/1_4_1/jaxws-guide.html> >> >> Thanks, >> Nithya >> >> Nithya Vijayakumar, Ph.D. >> Software Engineer, Cisco >> >> >> >> >> > > > > -- > http://www.qi4j.org <http://www.qi4j.org/> - New Energy for Java -- James Dixson Manager, Software Development CUAE Engineering, Cisco Systems (e) [email protected] (p) 512-336-3305 (m) 512-968-2116
