Thanks! Will try it out. Thanks, Nithya
-----Original Message----- From: Scott Comer (sccomer) Sent: Friday, January 23, 2009 8:29 AM To: [email protected] Subject: Re: Post to Etch developer community jd created the issue here: https://issues.apache.org/jira/browse/ETCH-30 i've attached to the issue a patch release for you to try. you can probably get it faster here: \\metreos-fs\scratch\wert\etch-1.0.2 thanks, 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) > <[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 >> >>
