Return-Path: Delivered-To: apmail-axis-java-dev-archive@www.apache.org Received: (qmail 19220 invoked from network); 10 Mar 2010 05:07:58 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 10 Mar 2010 05:07:58 -0000 Received: (qmail 60328 invoked by uid 500); 10 Mar 2010 05:07:29 -0000 Delivered-To: apmail-axis-java-dev-archive@axis.apache.org Received: (qmail 60078 invoked by uid 500); 10 Mar 2010 05:07:28 -0000 Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@axis.apache.org Delivered-To: mailing list java-dev@axis.apache.org Received: (qmail 60070 invoked by uid 99); 10 Mar 2010 05:07:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Mar 2010 05:07:28 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of amilasuriarachchi@gmail.com designates 74.125.92.144 as permitted sender) Received: from [74.125.92.144] (HELO qw-out-1920.google.com) (74.125.92.144) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Mar 2010 05:07:21 +0000 Received: by qw-out-1920.google.com with SMTP id 14so1256146qwa.62 for ; Tue, 09 Mar 2010 21:07:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=PW+eekaML5Z7TBRAvj2f7LWScdzuqHr1u26kjFQJ5gE=; b=IhHmEYZjGM7RCsL8ZplxJJlWYCvcjDhLL81dpt4y7Nb2IISAb0M7yv5ITpjnD8pqUe 6MSPwK1wPLe1C0K9mht67XvQJLxnFF+ql7Hmib1IhnqMsAAra8diBqyOGQaNfZ/PBygG vcuhoqNmx4mp7aPLHYAkkUjhaSTpqStVtxx2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=UztIWx7tzsb81IoNym1jWY7i1ev8/iRNbgqJGIyil2znQc1rPefdu8IyDwy10uolzt n2yeE7zOOQNJOU+HwqC3Y5BF3fErEiKCwYFnMPAUKosycH3A1OUgLsTWR84BqkobxuaX qCF2tlTmbd1HJwOOMVrL7fp8J6hMwnvjN64Fc= MIME-Version: 1.0 Received: by 10.229.226.145 with SMTP id iw17mr408650qcb.95.1268197619922; Tue, 09 Mar 2010 21:06:59 -0800 (PST) In-Reply-To: <474d01b01003090631l15fe8af1g3ecafebf990b592c@mail.gmail.com> References: <60708f4b1003082053h642a87f5ya01bb830e3c8ce60@mail.gmail.com> <474d01b01003090215m7be1a002o21f4aedf40f56e7c@mail.gmail.com> <60708f4b1003090507r385046f0j895d8d4bfdc9ecf0@mail.gmail.com> <474d01b01003090631l15fe8af1g3ecafebf990b592c@mail.gmail.com> Date: Wed, 10 Mar 2010 10:36:59 +0530 Message-ID: <60708f4b1003092106q59a120fcr47f40cc300111ce7@mail.gmail.com> Subject: Re: Making JAX-WS services configurable (with a services.xml or Axis2 specific annotations) From: Amila Suriarachchi To: java-dev@axis.apache.org Content-Type: multipart/alternative; boundary=00163646db3ea3f6a004816b44d8 X-Virus-Checked: Checked by ClamAV on apache.org --00163646db3ea3f6a004816b44d8 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 9, 2010 at 8:01 PM, Sagara Gunathunga < sagara.gunathunga@gmail.com> wrote: > > > On Tue, Mar 9, 2010 at 6:37 PM, Amila Suriarachchi < > amilasuriarachchi@gmail.com> wrote: > >> >> >> On Tue, Mar 9, 2010 at 3:45 PM, Sagara Gunathunga < >> sagara.gunathunga@gmail.com> wrote: >> >>> >>> >>> On Tue, Mar 9, 2010 at 10:23 AM, Amila Suriarachchi < >>> amilasuriarachchi@gmail.com> wrote: >>> >>>> >>>> >>>> On Mon, Mar 8, 2010 at 5:39 PM, Andreas Veithen < >>>> andreas.veithen@gmail.com> wrote: >>>> >>>>> I also created a proof-of-concept [1] that shows the feasibility of >>>>> the services.xml based approach that I suggested in AXIS2-4611. It >>>>> implements a custom deployer that is based on ServiceDeployer, but >>>>> replaces the code that builds the initial AxisService object from the >>>>> WSDL by code that uses >>>>> org.apache.axis2.jaxws.description.DescriptionFactory. Of course this >>>>> introduces massive code duplication and is thus only valid as a >>>>> proof-of-concept. >>>> >>>> Apart from this I think when we introduce a new deployer then we need to >>>> have a different folder to >>>> deploy files and a different extension. >>>> >>>> >>>> >>>>> To do this properly, it would be necessary to modify >>>>> ServiceDeployer to create some sort of extension point that allows >>>>> JAX-WS to supply the initial AxisService description. >>>>> >>>> >>>> I think your intention here is to let users to deploy JAX-WS services as >>>> aar files which already >>>> have the service.xml. IMHO we need to add service.xml support to JAX-WS >>>> services. ie. jaxws jar files can have an optional service.xml file in the >>>> META-INF. >>>> >>>> AFAIK(please correct me if I wrong :)), at the initial statges Axis2 >>>> does not have the concept of custom deployers. So at that time (time when >>>> JAX-WS started) every thing deployed as .aar files. But latter there were >>>> problems with JAX-WS support in aar files and introduced thin new custom >>>> deployer concept to address this issue. Therefore adding JAX-WS support to >>>> .aar files may not be the best approach. >>>> >>> >>> Another important use case is to support JAX-WS based WAR archive >>> deployment , lot of people want to integrate web services as a part of their >>> web applications by adding AxisServlet in the web.xml file , this works >>> fine for native services.xml based web service deployment but AFAIK we can't >>> use WAR deployment with JAX-WS , >>> >> >> I have not tried this but I think it is possible. if you deploy a .jar >> file under WEB-INF/servicejars I think it is possible. >> > > > Nice to hear about such workaround for JAX-WS WAR deployment, I will try > out too . But having a descriptor file or annotations based JAX-WS > deployment approach will increase the 'ease of use ' of the project > specially when some one use build tools like Maven. > > 1.) In my experience service.xml based WAR based deployment is very simple > and fit well with build tools like Maven and Ant. Only requirement is to add > a services.xml into the WEB-INF/services directory no need to care about > location of the .calss files. we can use Maven/ant default behavior for > .class file locations ( classes or lib) and packaging . But in the > mentioned approach we have to place a JAR file inside the > WEB-INF/servicejars directory this may require to modify build script little > bit. It would be great if we can come up with a solution so that we only > place meta data file in the WEB-INF or WEB-INF/servicejars directory and > classes are loaded from default Classpath ( like in service.xml based WAR > deployment). > > > 2.) Most of the other Java web service frameworks support JAX-WS WAR > deployment only by placing a meta data file in the WEB-INF directory, if > we can support to similar approach it will help out for people who move in > to Axis2 from other frameworks. If they have a existing JAX-WS service they > only need to write a descriptor file in order to deploy on Axis2 container. > > Above scenarios can be specific for few use cases but IMO with the maturity > level of Axis2 project now we have to think about those aspects too. > > > >> >> >>> It's going to be a valuable feature if we can support for this. >>> >>> >>>> >>>> These are the options I can think of adding axis2 specific >>>> custermizations to JAX-WS. >>>> >>>> 1. Support optional services.xml file in META-INF >>>> Services.xml file is a too generic file. So people may confuse >>>> with some options with services.xml file. >>>> 2. Introduce new optional config file in META-INF (eg axis2-jaxws.xml) >>>> May have to duplicate some exising code in ServiceBuilder >>>> 3. Introduce axis2 specific anotations to JAX-WS >>>> May have problems with writting annotations to set the >>>> security polices. >>>> >>> >>> >>> Personally I like to have a descriptor file such as axis2-jaxws.xml or >>> usual service.xml rather introducing another set of axis2 specific >>> annotations. >>> >> >> Think about a scenario like this. Lets say some one has wirten a jax ws >> service already and they need to deploy it under 'transportSession' in that >> case isn't it easy to just add an anotation to existing jax ws web service >> class instead of writtng a new services.xml file? >> >> Infact there can be instances where services.xml is useful and annotations >> useful. >> > > I can agree with your ideas, each of this approaches have their own > specific usages, as an example sometimes people want to change some settings > when they deploy the application without recompiling source codes having a > descriptor file is a ideal for such use case. what about to support both > options ? > +1. I think that is the best way. For an example if we take a user who have deployed a jax-ws jar in a standalone server like WSO2 WSAS then they may not interested going for a web app or .aar file, but want to just put a services.xml file inside the .jar file itself or add some annotaions. On the other hand as you and Andreas has pointed out there are senarios where .aar support is important as well. thanks, Amila. > > Thanks, > > > >> >> thanks, >> Amila. >> >> >>> Axis2 already supports to JAX-WS deployment as a JAR file , it would be >>> great if we can utilize same JAR file with WAR deployment only adding a >>> descriptor file into the WEB-INF directory. >>> >>> Thanks, >>> >>> >>>> >>>> Thanks, >>>> Amila. >>>> >>>>> >>>>> Andreas >>>>> >>>>> [1] >>>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/AXIS2-4611/ >>>>> >>>>> On Mon, Mar 8, 2010 at 12:04, Isuru Suriarachchi >>>>> wrote: >>>>> > Hi all, >>>>> > >>>>> > Andreas has already reported an issue [1] regarding the inability to >>>>> > configure JAX-WS services. That is because we've removed support for >>>>> a >>>>> > services.xml. But there are many use cases where the user should be >>>>> able to >>>>> > configure the service according to his requirements. Following are >>>>> some of >>>>> > the very common examples. >>>>> > >>>>> > [1] Ability to deploy JAX-WS services in different scopes (session, >>>>> > application etc.) >>>>> > [2] Ability to set ServiceTCCL >>>>> > [3] Ability to specify service parameters >>>>> > >>>>> > In order to support these use cases, we have to support service >>>>> > customizations somehow. If allowing a services.xml file is not a >>>>> proper >>>>> > solution, I think defining Axis2 specific annotations whould be a >>>>> good >>>>> > solution for this issue. >>>>> > >>>>> > WDYT?.. >>>>> > >>>>> > Thanks, >>>>> > ~Isuru >>>>> > >>>>> > [1] https://issues.apache.org/jira/browse/AXIS2-4611 >>>>> > >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org >>>>> For additional commands, e-mail: java-dev-help@axis.apache.org >>>>> >>>>> >>>> >>>> >>>> -- >>>> Amila Suriarachchi >>>> WSO2 Inc. >>>> blog: http://amilachinthaka.blogspot.com/ >>>> >>> >>> >>> >>> -- >>> Sagara Gunathunga >>> >>> Blog - http://ssagara.blogspot.com >>> Web - http://people.apache.org/~sagara/ >>> >> >> >> >> -- >> Amila Suriarachchi >> WSO2 Inc. >> blog: http://amilachinthaka.blogspot.com/ >> > > > > -- > Sagara Gunathunga > > Blog - http://ssagara.blogspot.com > Web - http://people.apache.org/~sagara/ > -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ --00163646db3ea3f6a004816b44d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Mar 9, 2010 at 8:01 PM, Sagara G= unathunga <sagara.gunathunga@gmail.com> wrote:


On Tue, Mar 9, 2010 at= 6:37 PM, Amila Suriarachchi <amilasuriarachchi@gmail.com>= ; wrote:


On Tue, Mar 9, 2010 at 3:45 PM, Sag= ara Gunathunga <sagara.gunathunga@gmail.com> wrote= :


On Tue, Mar 9, 2010 at 10:23 AM, Am= ila Suriarachchi <amilasuriarachchi@gmail.com> wro= te:


On Mon, Mar 8, 2010 at 5:39 PM, And= reas Veithen <andreas.veithen@gmail.com> wrote:
I also created a proof-of-concept [1] that shows the feasibility of
the services.xml based approach that I suggested in AXIS2-4611. It
implements a custom deployer that is based on ServiceDeployer, but
replaces the code that builds the initial AxisService object from the
WSDL by code that uses
org.apache.axis2.jaxws.description.DescriptionFactory. Of course this
introduces massive code duplication and is thus only valid as a
proof-of-concept.
Apart from this I think when we i= ntroduce a new deployer then we need to have a different folder to
depl= oy files and a different extension.

=A0
To do this properly, it would be necessary to modify
ServiceDeployer to create some sort of extension point that allows
JAX-WS to supply the initial AxisService description.

I think your intention here is to let users to deploy JAX-WS serv= ices as aar files which already
have the service.xml. IMHO we need to a= dd service.xml support to JAX-WS services. ie. jaxws jar files can have an = optional service.xml file in the META-INF.

AFAIK(please correct me if I wrong :)), at the initial statges Axis2 do= es not have the concept of custom deployers. So at that time (time when JAX= -WS started) every thing deployed as .aar files. But latter there were prob= lems with JAX-WS support in aar files and introduced thin new custom deploy= er concept to address this issue. Therefore adding JAX-WS support to .aar f= iles may not be the best approach.

Another important use case is to su= pport JAX-WS based WAR archive deployment , lot of people want to integrate= web services as a part of their web=A0 applications by adding AxisServlet= =A0 in the web.xml file , this works fine for native services.xml based web= service deployment but AFAIK we can't use WAR deployment with JAX-WS ,=

I have not tried this but I think it is p= ossible. if you deploy a .jar file under WEB-INF/servicejars I think it is = possible.


Nice to hear about= such workaround for JAX-WS WAR deployment, I will try out too . But having= a descriptor file or annotations based JAX-WS deployment approach will inc= rease the 'ease of use ' of the project specially when some one use= build tools like Maven.

1.) In my experience service.xml based WAR based deployment is very sim= ple and fit well with build tools like Maven and Ant. Only requirement is t= o add a services.xml into the WEB-INF/services directory no need to care ab= out location of the .calss files. we can use Maven/ant default behavior for= .class file locations ( classes or lib) and packaging . But in the=A0 ment= ioned approach we have to place a JAR file inside the WEB-INF/servicejars d= irectory this may require to modify build script little bit. It would be gr= eat if we can come up with a solution so that we only place meta data file = in the WEB-INF or WEB-INF/servicejars directory and classes are loaded from= default Classpath ( like in service.xml based WAR deployment).=A0


2.) Most of the other Java web service frameworks support=A0 JAX-WS= WAR deployment only=A0 by placing a meta data file in the=A0 WEB-INF direc= tory, if we can support to similar approach it will help out for people who= move in to Axis2 from other frameworks. If they have a existing JAX-WS ser= vice they only need to write a descriptor file in order to deploy on Axis2 = container.

Above scenarios can be specific for few use cases but IMO with the matu= rity level of Axis2 project now we have to think about those aspects too.= =A0
=A0
=A0=A0
=A0
It's going to be a valuable feature if = we can support for this.=A0
=A0

These are the options I can think of adding axis2 specific custermizati= ons to JAX-WS.

1. Support optional services.xml file in META-INF
= =A0=A0=A0=A0=A0=A0=A0=A0 Services.xml file is a too generic file. So people= may confuse with some options with services.xml file.
2. Introduce new optional config file in META-INF (eg axis2-jaxws.xml)
= =A0=A0=A0=A0=A0=A0=A0=A0=A0 May have to duplicate some exising code in Serv= iceBuilder
3. Introduce axis2 specific anotations to JAX-WS
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 May have problems with writting annotations to set th= e security polices.


Personally I like to have a des= criptor file such as axis2-jaxws.xml or usual service.xml rather introducin= g another set of axis2 specific annotations.

Think about a scenario like this. Lets say some one has wirt= en a jax ws service already and they need to deploy it under 'transport= Session' in that case isn't it easy to just add an anotation to exi= sting jax ws web service class instead of writtng a new services.xml file?<= br>
Infact there can be instances where services.xml is useful and annotati= ons useful.

=A0I can agree with = your ideas, each of this approaches have their own specific usages, as an e= xample sometimes people want to change some settings when they deploy the a= pplication without recompiling source codes having a descriptor file is a i= deal for such use case. what about to support both options ?

+1.

I think that is th= e best way. For an example if we take a user who have deployed a jax-ws jar= in a standalone server like WSO2 WSAS then they may not interested going f= or a web app or .aar file, but want to just put a services.xml file inside = the .jar file itself or add some annotaions.

On the other hand as you and Andreas has pointed out there are senarios= where .aar support is important as well.

thanks,
Amila.

<= br>=A0

Thanks,

=A0

thanks,
Amila.
=A0
Axis2 already supports to JAX-WS deployment= as a JAR file , it would be great if we can utilize same JAR file with WAR= deployment only adding a descriptor file into the WEB-INF directory.=A0
Thanks,=A0
=A0

Thanks,
Amila.

Andreas

[1] https://svn.apache.org/repos/= asf/axis/axis2/java/core/scratch/java/veithen/AXIS2-4611/

On Mon, Mar 8, 2010 at 12:04, Isuru Suriarachchi <isurues@gmail.com> wrote:
> Hi all,
>
> Andreas has already reported an issue [1] regarding the inability to > configure JAX-WS services. That is because we've removed support f= or a
> services.xml. But there are many use cases where the user should be ab= le to
> configure the service according to his requirements. Following are som= e of
> the very common examples.
>
> [1] Ability to deploy JAX-WS services in different scopes (session, > application etc.)
> [2] Ability to set ServiceTCCL
> [3] Ability to specify service parameters
>
> In order to support these use cases, we have to support service
> customizations somehow. If allowing a services.xml file is not a prope= r
> solution, I think defining Axis2 specific annotations whould be a good=
> solution for this issue.
>
> WDYT?..
>
> Thanks,
> ~Isuru
>
> [1] https://issues.apache.org/jira/browse/AXIS2-4611
>

------------------------------------------= ---------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org




--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.b= logspot.com/



--
Sagara Gunathunga

Blog - http://ssagara.blogspot.com
Web = - http://= people.apache.org/~sagara/



--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blog= spot.com/



--
Amila Suria= rachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
--00163646db3ea3f6a004816b44d8--