Ah JD beat me to it. The issue is: https://issues.apache.org/jira/browse/ETCH-30
On Fri, Jan 23, 2009 at 10:15 AM, James Dixson <[email protected]> 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) > <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of Niclas >> Hedhman >> Sent: Wednesday, January 21, 2009 11:37 PM >> To: [email protected] >> Subject: Re: Post to Etch developer community >> >> On Wed, Jan 21, 2009 at 10:44 PM, Nithya Vijayakumar (nvijayak) >> <[email protected]> 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 implementation.java type. Tuscany is obviously a lot more >> capable than you initially gave me the impression of. >> >> Cheers >> Niclas >> -- >> http://www.qi4j.org - New Energy for Java >> >
