]
Alessio Soldano updated JBWS-2916:
----------------------------------
Fix Version/s: jbossws-cxf-3.3.0
jbossws-metro-3.3.0
jbossws-native-3.3.0
Properly setup deployment classloader
-------------------------------------
Key: JBWS-2916
URL:
https://jira.jboss.org/jira/browse/JBWS-2916
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: jbossws-cxf, jbossws-integration, jbossws-jaxrpc, jbossws-metro,
jbossws-native
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Fix For: jbossws-cxf-3.3.0, jbossws-metro-3.3.0, jbossws-native-3.3.0
JAXRPC and JAXWS deployments need to be associated with different classloaders at
runtime. This is basically because endpoint implementations (and handlers, etc.) need to
be able to correctly use features/functionalities that requires factories' resolution
through the JBossWS SPI ServiceLoader and/or classloader's resource loading in
general.
This means that the whole deployment unit have to be associated with a classloader that
correctly sees the stuff in the jaxrpc deployer folder first for jaxrpc deployments (the
same applies for jaxws deployer and deployments).
Currently the classloader built at deployment time for a given ws deployment unit points
to the deployment archive. References to classes/resources outside of the deployment are
resolved through the BaseClassLoader that "sees" the whole server structure all
together, including the deployers folders. This is of course a problem here.
An idea is to provide additional libraries with the META-INF/services/.. stuff only. The
CXF/Metro ones should be installed in common/lib, while another one for jaxrpc/native
should be included in the jbossws-jaxrpc.deployer. The latter has to be used by a describe
stage deployer for adding additional classpath entries to the deployment unit before the
classload phase for jaxrpc endpoint deployments.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: