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. 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.
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 <isur...@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-unsubscr...@axis.apache.org For additional commands, e-mail: java-dev-h...@axis.apache.org
