axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: Making JAX-WS services configurable (with a services.xml or Axis2 specific annotations)
Date Tue, 09 Mar 2010 11:59:49 GMT
My proposal (to add an extension point to ServiceDeployer to allow
JAX-WS to inject AxisService descriptions built from JAX-WS
annotations) has the following advantages:
* The familiar services.xml syntax applies. No new descriptor formats
or annotations are necessary.
* No need for a new deployer; JAX-WS services can be deployed from an AAR.
* JAX-WS services can benefit from the other advantages of AAR files
(e.g. embedded JARs).
* Works with WARs (i.e. with an exploded AAR bundled inside the WAR).
* Restores compatibility with earlier Axis2 versions (and with what is
promised in the Axis2 documentation).
* Possibility to mix JAX-WS services with other types of services in a
single AAR.
* Relatively easy to implement and not much new code required.
However, it will require a refactoring of ServiceDeployer to introduce
a new API (which could be useful for other purposes in the future).

Andreas

On Tue, Mar 9, 2010 at 11:15, 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 , 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.
> 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 <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 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/
>

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


Mime
View raw message