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]] 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://ws.apache.org/axis2/1_4_1/jaxws-guide.html >> >> Thanks, >> Nithya >> >> Nithya Vijayakumar, Ph.D. >> Software Engineer, Cisco >> >> >> >> >> > > > > -- > 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
