etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Dixson <>
Subject Re: Post to Etch developer community
Date Tue, 20 Jan 2009 20:01:17 GMT


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.


On 1/20/09 1:07 PM, "J.D. Liau (jliau)" <> 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: [] On Behalf Of Niclas
> Hedhman
> Sent: Tuesday, January 20, 2009 9:40 AM
> To:
> 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)
> <> 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.
>> Thanks,
>> Nithya
>> Nithya Vijayakumar, Ph.D.
>> Software Engineer, Cisco
> --
> - New Energy for Java

James Dixson
Manager, Software Development
CUAE Engineering, Cisco Systems
(p) 512-336-3305
(m) 512-968-2116

View raw message