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 Fri, 23 Jan 2009 16:15:01 GMT

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.


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 us.
> 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