[jboss-user] [JBoss Web Services Development] New message: "Re: Providing JAX-RPC functionalities with CXF and Metro stacks"

[Alessio Soldano]

User 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