incubator-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 Fri, 23 Jan 2009 22:35:43 GMT
Thanks! Will try it out.


-----Original Message-----
From: Scott Comer (sccomer) 
Sent: Friday, January 23, 2009 8:29 AM
Subject: Re: Post to Etch developer community

jd created the issue here:

i've attached to the issue a patch release for you to try.

you can probably get it faster here:


scott out

James Dixson wrote:
> Nithya,
> This sounds like an issue related to some need for expediency  on your

> part rather than a though out design consideration. Lets do this, I 
> will open an issue against Etch about a default constructor, but I 
> will not schedule the issue to be fixed until the design question is 
> better understood.
> In that issue we can post a patch to 1.0.x that will generate a 
> default constructor that you can apply to the 1.0.x code base to try 
> out and see if that solves your immediate problem.
> But before we can serious consider including this in mainline, we 
> really need to understand if this is something that is important 
> beyond your very specific implementation.
> --
> james
> On Thu, Jan 22, 2009 at 11:14 AM, Nithya Vijayakumar (nvijayak) 
> <> wrote:
>> We want to expose the underlying Etch services as SOAP. So no 
>> additional server side implementations needed. Our requirements is 
>> not to expose Service A to SOAP, but expose Etch Service A to SOAP. I

>> understand that if we are starting the product from scratch we have
several options.
>> Instantiating a service without a default constructor is one thing, 
>> but data transfer doesn't happen in the same way. From our experience

>> with many web service solutions (CXF, ServiceMix, Axis etc) for any 
>> serializable communication to happen, we need no-arg constructors for

>> the data objects.
>> We have been using Tuscany for well over a year now and have made 
>> many modifications to its original source that we are in the process 
>> of contributing back to the community. May be I wasn't clear in my 
>> earlier explanation. We need POJOs for use with Tuscany. We need 
>> default constructors for exposing applications as SOAP with Axis 2.
>> Our current framework's scope is well beyond just SOAP and Etch and 
>> it supports a variety of features. The supported model for our 
>> application is deployment within Tomcat and Jetty containers. This 
>> framework is already being used by many products in our organization,

>> hence moving to spring framework right now would be not feasible for
>> We understand that the requirements for no-arg constructors stems 
>> from the design of our architecture and our choice of tools. However,

>> we are facing a requirement to expose Etch as SOAP (in our current 
>> Tuscany based framework). Hence the request.
>> Thanks,
>> Nithya
>> -----Original Message-----
>> From: [] On Behalf Of 
>> Niclas Hedhman
>> Sent: Wednesday, January 21, 2009 11:37 PM
>> To:
>> Subject: Re: Post to Etch developer community
>> On Wed, Jan 21, 2009 at 10:44 PM, Nithya Vijayakumar (nvijayak) 
>> <> wrote:
>>> 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.
>> But you have not answered if you are aware that you introduce one 
>> extra tier of network communications? Is that what you really are 
>> after, or do you want to provide an additional binding to the
underlying service?
>> If you let Etch IDL generate you the server bindings, you will need 
>> to provide an implementation, and IMHO, that is an easy integration 
>> point, whereas you will have an additional to Etch transport and SOAP

>> transport for the same service. It all depends on your usecase.
>> Furthermore, I have not used Tuscany myself, but just from 3 minutes 
>> worth of browsing the documentation, it is pretty clear that the 
>> default constructor is not a hard requirement. For instance, Tuscany 
>> allows Spring, Spring allows for bean factories, hence no need for 
>> default constructor. Tuscany allows for OSGi services, which are not 
>> instantiable at all and should be looked up in a service registry, 
>> hence no need for default constructor. You need to look beyond the 
>> HelloWorld and the simple type. Tuscany is 
>> obviously a lot more capable than you initially gave me the
impression of.
>> Cheers
>> Niclas
>> --
>> - New Energy for Java

View raw message