[jboss-dev-forums] [Design of POJO Server] - First real SARDeployer porting issue

[scott.stark@jboss.org]

The SARDeployer is getting deployed in the MC and the legacy jmx kernel is setup for the mbeans, and the SARDeployer is attempting to deploy the *-service.xml mbeans. This is currently failing due to a change in how the deployment class loader is handled

In jboss-4.0.x some deployers have a classpath notion, others do not. For the current failing deployment (jboss-aop-jdk50.deployer, ignoring this needs to be ported to the new VDF) , there are nested jars that are not getting added to the deployment classpath. In jboss-4.0.x this would be done by the nested jars falling through the JARDeployer, which added any jars not looking like deployments to the classpath.

In the new VDF, the deployment classpath is managed by the ClassLoadingDeployer, and it operates on classpath metadata from the deployment (META-INF/Class-Path, jars a deployer says should be on the classpath (ear/lib, war/lib), custom classloading.xml descriptor, etc.). A JARDeployer does not really fit into the VDF scheme because every deployer sees every deployment. One way to handle this and maintain backward compatibility with implicit classpath jars nested in a deployment would be to add a notion to the AspectDeployer interface regarding whether deployment content that is not accepted by a deployer should be added to the containing deployment classpath. For the SARDeployer this would be, for the EARDeployer, WARDeployer it would be false.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964433#3964433

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964433