Mailing-List: contact etch-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: etch-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of sccomer@cisco.com designates
 171.71.176.71 as permitted sender)
Message-ID: <4979F048.7040401@cisco.com>
Date: Fri, 23 Jan 2009 10:28:56 -0600
From: "scott comer (sccomer)" <sccomer@cisco.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: etch-dev@incubator.apache.org
Subject: Re: Post to Etch developer community
References: 
 <4465623F8C892B4C829F7B4D09A4C2B906B7CDFA@xmb-sjc-234.amer.cisco.com>
	 <caf30e2a0901212336i40c20fbeuaae5b2889778538e@mail.gmail.com>
	 <4465623F8C892B4C829F7B4D09A4C2B906B7D1E6@xmb-sjc-234.amer.cisco.com>
 <b89544e50901230815m6166ef35n1ef4b979100956ec@mail.gmail.com>
In-Reply-To: <b89544e50901230815m6166ef35n1ef4b979100956ec@mail.gmail.com>
Content-Type: multipart/mixed;
 boundary="------------080600090108050302070408"

--------------080600090108050302070408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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)
> <nvijayak@cisco.com> 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: hedhman@gmail.com [mailto:hedhman@gmail.com] On Behalf Of Niclas
>> Hedhman
>> Sent: Wednesday, January 21, 2009 11:37 PM
>> To: etch-dev@incubator.apache.org
>> Subject: Re: Post to Etch developer community
>>
>> On Wed, Jan 21, 2009 at 10:44 PM, Nithya Vijayakumar (nvijayak)
>> <nvijayak@cisco.com> 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
>>
>>     

--------------080600090108050302070408--