JBoss development,
A new message was posted in the thread "Providing JAX-RPC functionalities with CXF
and Metro stacks":
http://community.jboss.org/message/526583#526583
Author : Alessio Soldano
Profile :
http://community.jboss.org/people/alessio.soldano@jboss.com
Message:
--------------------------------------------------------------
The deployment processing issue has been solved basically leveraging the current
architecture of ws deployers in AS trunk. The webservice processing in the deployers is
currently splitted in a quite fine-grained group of AS real deployers.
In few words, adding a couple of flags (attributes) to both stacks' deployers for
marking them as being able to deal with jaxrpc/jaxws deployements, we've been able to
make them run just for the deployements they're meant for (the deployment type is
detected early in the real phase). Thanks to the AS deployers' inputs/outputs and the
current JBWS deployers' modularity, there's been no need to provide implementation
of new deployers, a proper combination of the already existing one is fine.
So, the JBossWS-CXF and JBossWS-Metro stacks now come with a -jboss-beans.xml descriptor
that is added to jbossws-jaxrpc.deployer folder (see below) and that basically pulls in
the chain 6 deployers normally used by JBossWS-Native. Those are marked forJaxWs=false in
this case and hence used for jaxrpc only.
The next step has been to properly factor our all the non-jaxrpc /
non-jbws-native-specific META-INF/services/... from the jbossws-native-core.jar module.
This allows that jar to always stay in $JBOSS_HOME/client and $JBOSS_HOME/common/lib
regardless of what WS stack is installed. As a side effect, it also goes in the direction
of moving most of the ws related jars out of the deployers/jbossws.deployer dir, which
reduce the AS distro size ;-)
Those service configuration are moved to a descriptor only jar
(jbossws-native-services.jar) and that jar is installed by default in the new
deployers/jbossws-jaxrp.deployer dir, along with the factories configuration (working the
same way) we already have in jbossws-native-factories.jar. A separate classloader is
specified through a jboss-classloading.xml file for that jbossws-jaxrpc.deployer, to
prevent those services configuration from interfering with the other deployed jbws stack.
Of course those descriptor only are included in $JBOSS_HOME/client and
$JBOSS_HOME/common/lib as usual when the native stack is installed instead.
The following step has been to ensure the proper classpath is setup when creating the
classloader that will be used at runtime for a given endpoint deployment.
I took inspiration from the Seam/Weld integration into AS 5 here. We provide a deployer
that extends the org.jboss.deployers.vfs.plugins.classloader.UrlIntegrationDeployer for
adding classpath entries to the DeploymentUnit during the describe phase. JAX-RPC
deployments only are touched here: the jbossws-native-services.jar and
jbossws-native-factories.jar are added on top of the classpath. This basically results in
the Native stack implementations being configured for serving requests to jaxrpc
deployements.
There're actually 4 slightly different deployers of this kind, to deal with server
deployments and client deployments (service-ref through servlet, ejb or standalone
client).
Something I've had problem with here is how to detect jaxrpc deployments at describe
phase; as I mentioned before, we already do that, but in real phase. The reason for doing
that at real phase is simply that jaxws endpoint can be specified through annotations
hence the classes need to be loaded first.
For server side the problem is easily solved setting
org.jboss.wsf.spi.metadata.webservices.WebservicesMetadata.class as input to the new
deployer, as that's attached to the DeploymentUnit only when a webservices.xml is
included in the deployment (ie. we have a jaxrpc endpoint). Considering annotations are
not part of the game for JAXRPC, the service-ref deployement (client side) currently works
by checking the ServiceReferencesMetaData from
EjbJarMetaData/WebMetaData/ApplicationClientMetaData for the existence of references to a
jaxrpc-mapping. Suggestions are welcome here, if any.
Finally, the already available StackConfig bean is injected into the new deployers, to
allow them to actually run just when a non-native stack is installed, while always being
provided in the AS though a -jboss-beans.xml file in jbossws-jaxrpc.deployer (since
they're container specific).
--------------------------------------------------------------
To reply to this message visit the message page:
http://community.jboss.org/message/526583#526583