etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nithya Vijayakumar (nvijayak)" <>
Subject Re: Post to Etch developer community
Date Wed, 21 Jan 2009 21:44:11 GMT
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.


-----Original Message-----

From: James Dixson (jadixson)

Sent: Tuesday, January 20, 2009 2:01 PM


Subject: Re: Post to Etch developer community



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

> 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