You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@etch.apache.org by "Nithya Vijayakumar (nvijayak)" <nv...@cisco.com> on 2009/01/17 02:17:04 UTC
Post to Etch developer community
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/user@tuscany.apache.org/msg00951.html
http://ws.apache.org/axis2/1_4_1/jaxws-guide.html
Thanks,
Nithya
Nithya Vijayakumar, Ph.D.
Software Engineer, Cisco
Re: Post to Etch developer community
Posted by James Dixson <ja...@cisco.com>.
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)" <jl...@cisco.com> 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: hedhman@gmail.com [mailto:hedhman@gmail.com] On Behalf Of Niclas
> Hedhman
> Sent: Tuesday, January 20, 2009 9:40 AM
> To: etch-dev@incubator.apache.org
> 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)
> <nv...@cisco.com> 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/user@tuscany.apache.org/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) jadixson@cisco.com
(p) 512-336-3305
(m) 512-968-2116
RE: Post to Etch developer community
Posted by "J.D. Liau (jliau)" <jl...@cisco.com>.
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: hedhman@gmail.com [mailto:hedhman@gmail.com] On Behalf Of Niclas
Hedhman
Sent: Tuesday, January 20, 2009 9:40 AM
To: etch-dev@incubator.apache.org
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)
<nv...@cisco.com> 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/user@tuscany.apache.org/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
Re: Post to Etch developer community
Posted by Niclas Hedhman <ni...@hedhman.org>.
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)
<nv...@cisco.com> 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/user@tuscany.apache.org/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