Mailing-List: contact etch-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: etch-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of jliau@cisco.com designates
 171.68.10.87 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Post to Etch developer community
Date: Tue, 20 Jan 2009 11:07:28 -0800
Message-ID: 
 <4C0FAAC489C8B74F96BEAD85EAEB262507DA0C82@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <caf30e2a0901200739l6013f1dfue9f9483d4c271f74@mail.gmail.com>
Thread-Topic: Post to Etch developer community
Thread-Index: Acl7FWnUHzcMFDuzSxSbD5uowtMIugAGCfvg
References: 
 <4465623F8C892B4C829F7B4D09A4C2B906B0924A@xmb-sjc-234.amer.cisco.com>
 <caf30e2a0901200739l6013f1dfue9f9483d4c271f74@mail.gmail.com>
From: "J.D. Liau (jliau)" <jliau@cisco.com>
To: <etch-dev@incubator.apache.org>

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.=20

>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.  =20

-----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)
<nvijayak@cisco.com> wrote:
> Etch Developers,
>
> Our current posting is to request no-arg default constructor in all=20
> generated Etch java sources.
>
> We are using Apache Etch for our services. We have a requirement to=20
> 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=20
> 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=20
> 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=20
> no-arg default constructor for even things like WSDL generation.=20
> Further when we would like to serialize objects to XML using libraries

> like Xstream/JAXB, which in turn try to construct objects before=20
> serializing them to XML using the default constructor. Even when=20
> 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=20
> with Axis 2 and removed the no-arg constructors for complex objects=20
> and the service didn't deploy.
>
> We are adding some references to this topic. We hope the Etch=20
> 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