axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Afkham Azeez (JIRA)" <>
Subject [jira] Commented: (AXIS2-4611) JAX-WS services can no longer be deployed as AAR
Date Thu, 06 Jan 2011 13:48:49 GMT


Afkham Azeez commented on AXIS2-4611:

Perhaps, what we could do is have a mechanism of associating different types of services with
a services.xml file. So, the different deployers will create the base AxisService, and then
call a utility passing in that AxisService (and perhaps the location of a services.xml file).
That utility will parse that services.xml file, and populate more information into the AxisService.
This utility should be called before the registered AxisObservers are called.

> JAX-WS services can no longer be deployed as AAR
> ------------------------------------------------
>                 Key: AXIS2-4611
>                 URL:
>             Project: Axis2
>          Issue Type: Bug
>          Components: jaxws
>    Affects Versions: 1.5.1, 1.5, 1.4.1, 1.4
>            Reporter: Andreas Veithen
> The JAX-WS guide [1] makes the following statement:
> [quote]
> Axis2 provides two mechanisms for deploying JAX-WS services:
> * The service may be packaged and deployed as an AAR, just like any other service within
Axis2. Like with all AARs, a services.xml file containing the relevant metadata is required
for the service to deploy correctly.
> * The service may be packaged in a jar file and placed into the servicejars directory.
The JAXWSDeployer will examine all jars within that directory and deploy those classes that
have JAX-WS annotations which identify them as Web services.
> [/quote]
> This is no longer true. The support for the first scenario has been eliminated by the
change in r646585 [2]. The commit comment explains the reason for this change as follows:
"This is no longer needed now that JAXWS annotated endpoints can be deployed in Axis2." This
argument is flawed because service.xml allows to configure the services in ways that are not
supported by JAXWSDeployer. Here are some examples of valid use cases which could easily be
satisfied if Axis2 supported JAX-WS services deployed as an AAR:
> * AXIS2-4045
> *
> *
> *
> Other people have complained about the missing AAR/service.xml support, but without explaining
their use case:
> *
> *
> *
> *
> A closer look at r646585 reveals that the AAR support was actually considered experimental
or at least not fit for production use. Therefore, simply rolling back that change is not
an option. Analyzing the code in JAXWSDeployer and JAXWSMessageReceiver, it is also clear
that a JAX-WS service can only work if the AxisService description has been created by org.apache.axis2.jaxws.description.DescriptionFactory.
This is not the case if the service is deployed by ServiceDeployer (which is the component
that deploys AAR files and parses service.xml). Interestingly, ServiceDeployer supports two
approaches to build an AxisService:
> 1. The AxisService object is entirely built from information in service.xml.
> 2. The AxisService object is built from a WSDL, and this description is then completed
with the information from the service.xml file.
> Maybe JAX-WS services can be supported using an approach similar to item 2, i.e. by letting
DescriptionFactory build the initial AxisService description and then add the information
from the service.xml to that description.
> [1]
> [2]

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message