Return-Path: 
 <etch-dev-return-343-apmail-incubator-etch-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-etch-dev-archive@locus.apache.org
Received: (qmail 83851 invoked from network); 23 Jan 2009 22:36:13 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 23 Jan 2009 22:36:13 -0000
Received: (qmail 95254 invoked by uid 500); 23 Jan 2009 22:36:13 -0000
Delivered-To: apmail-incubator-etch-dev-archive@incubator.apache.org
Received: (qmail 95238 invoked by uid 500); 23 Jan 2009 22:36:13 -0000
Mailing-List: contact etch-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:etch-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:etch-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:etch-dev@incubator.apache.org>
List-Id: <etch-dev.incubator.apache.org>
Reply-To: etch-dev@incubator.apache.org
Delivered-To: mailing list etch-dev@incubator.apache.org
Received: (qmail 95227 invoked by uid 99); 23 Jan 2009 22:36:13 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Jan 2009 14:36:13 -0800
X-ASF-Spam-Status: No, hits=-4.0 required=10.0
	tests=RCVD_IN_DNSWL_MED,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of nvijayak@cisco.com designates
 171.71.176.71 as permitted sender)
Received: from [171.71.176.71] (HELO sj-iport-2.cisco.com) (171.71.176.71)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Jan 2009 22:36:03 +0000
X-IronPort-AV: E=Sophos;i="4.37,314,1231113600";
   d="scan'208";a="125404974"
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
  by sj-iport-2.cisco.com with ESMTP; 23 Jan 2009 22:35:43 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0NMZh1A024723
	for <etch-dev@incubator.apache.org>; Fri, 23 Jan 2009 14:35:43 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
 [128.107.191.100])
	by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0NMZhiD028646
	for <etch-dev@incubator.apache.org>; Fri, 23 Jan 2009 22:35:43 GMT
Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by
 xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 23 Jan 2009 14:35:43 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Post to Etch developer community
Date: Fri, 23 Jan 2009 14:35:43 -0800
Message-ID: 
 <AF319E9E472AE448BD735D8ACE8240A3305C4C@xmb-sjc-231.amer.cisco.com>
In-Reply-To: <4979F048.7040401@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Post to Etch developer community
Thread-Index: Acl9fBiy5M6G3W6MQX6VtbYbrR963AALsKcw
References: 
 <4465623F8C892B4C829F7B4D09A4C2B906B7CDFA@xmb-sjc-234.amer.cisco.com>
	 <caf30e2a0901212336i40c20fbeuaae5b2889778538e@mail.gmail.com>
	 <4465623F8C892B4C829F7B4D09A4C2B906B7D1E6@xmb-sjc-234.amer.cisco.com>
 <b89544e50901230815m6166ef35n1ef4b979100956ec@mail.gmail.com>
 <4979F048.7040401@cisco.com>
From: "Nithya Vijayakumar (nvijayak)" <nvijayak@cisco.com>
To: <etch-dev@incubator.apache.org>
X-OriginalArrivalTime: 23 Jan 2009 22:35:43.0100 (UTC)
 FILETIME=[ED01CBC0:01C97DAA]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5136; t=1232750143;
 x=1233614143;
	c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=nvijayak@cisco.com;
	z=From:=20=22Nithya=20Vijayakumar=20(nvijayak)=22=20<nvijaya
	k@cisco.com>
	|Subject:=20RE=3A=20Post=20to=20Etch=20developer=20communit
	y
	|Sender:=20;
	bh=PuBvOK39FeSTKRAmafBXge9jNbDJ0qeKw4OFn20Iz34=;
	b=UhKDI8Pxxhm9TJ8jGOw4+GE3gBxb3MUUZCm8dgANLqbdGJ5+g7Upu00StB
	tkj/tA3lWQrfs+U5T8VSTN8hgp2PsGqzH/bPYTSDOWkDzEqW//EEo4qR3/9g
	/BKdB59rAT;
Authentication-Results: sj-dkim-2; header.From=nvijayak@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; );
X-Virus-Checked: Checked by ClamAV on apache.org

Thanks! Will try it out.

Thanks,
Nithya=20

-----Original Message-----
From: Scott Comer (sccomer)=20
Sent: Friday, January 23, 2009 8:29 AM
To: etch-dev@incubator.apache.org
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=20
> will open an issue against Etch about a default constructor, but I=20
> will not schedule the issue to be fixed until the design question is=20
> better understood.
>
> In that issue we can post a patch to 1.0.x that will generate a=20
> default constructor that you can apply to the 1.0.x code base to try=20
> out and see if that solves your immediate problem.
>
> But before we can serious consider including this in mainline, we=20
> really need to understand if this is something that is important=20
> beyond your very specific implementation.
>
> --
> james
>
>
> On Thu, Jan 22, 2009 at 11:14 AM, Nithya Vijayakumar (nvijayak)=20
> <nvijayak@cisco.com> wrote:
>  =20
>> We want to expose the underlying Etch services as SOAP. So no=20
>> additional server side implementations needed. Our requirements is=20
>> 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,=20
>> but data transfer doesn't happen in the same way. From our experience

>> with many web service solutions (CXF, ServiceMix, Axis etc) for any=20
>> 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=20
>> many modifications to its original source that we are in the process=20
>> of contributing back to the community. May be I wasn't clear in my=20
>> earlier explanation. We need POJOs for use with Tuscany. We need=20
>> default constructors for exposing applications as SOAP with Axis 2.
>>
>> Our current framework's scope is well beyond just SOAP and Etch and=20
>> it supports a variety of features. The supported model for our=20
>> application is deployment within Tomcat and Jetty containers. This=20
>> 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=20
>> 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=20
>> Tuscany based framework). Hence the request.
>>
>> Thanks,
>> Nithya
>>
>> -----Original Message-----
>> From: hedhman@gmail.com [mailto:hedhman@gmail.com] On Behalf Of=20
>> 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)=20
>> <nvijayak@cisco.com> wrote:
>>    =20
>>> Hi all,
>>>
>>> Our requirement to use a JAVA POJO comes from Apache Tuscany. We did

>>> a
>>>      =20
>>> elaborate study of the different web services applications available

>>> and found Apache Tuscany to be the most easy to use and extendable=20
>>> software for our cause. Tuscany is based on a Service Component=20
>>> Architecture. It supports java and a few other languages.
>>>      =20
>> But you have not answered if you are aware that you introduce one=20
>> extra tier of network communications? Is that what you really are=20
>> 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=20
>> to provide an implementation, and IMHO, that is an easy integration=20
>> 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=20
>> worth of browsing the documentation, it is pretty clear that the=20
>> default constructor is not a hard requirement. For instance, Tuscany=20
>> allows Spring, Spring allows for bean factories, hence no need for=20
>> default constructor. Tuscany allows for OSGi services, which are not=20
>> instantiable at all and should be looked up in a service registry,=20
>> hence no need for default constructor. You need to look beyond the=20
>> HelloWorld and the simple implementation.java type. Tuscany is=20
>> obviously a lot more capable than you initially gave me the
impression of.
>>
>> Cheers
>> Niclas
>> --
>> http://www.qi4j.org - New Energy for Java
>>
>>    =20