4 Replies Latest reply on Aug 11, 2006 3:47 PM by starksm64

    First real SARDeployer porting issue

    starksm64

      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 true, for the EARDeployer, WARDeployer it would be false.

        • 1. Re: First real SARDeployer porting issue

           

          "scott.stark@jboss.org" wrote:
          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.


          This is what I originally defined as the JAR structure deployer.

          • 2. Re: First real SARDeployer porting issue
            starksm64

            Ok, maybe that is what is needed. An alternative would be to allow the ClassLoadingDeployer to run last during the structural phase, and first during the deployment phase. Don't know if other deployers/aspects would benefit from similar alternate orderings.

            • 3. Re: First real SARDeployer porting issue
              starksm64

              The next issue is that the thread context class loader seen in the mbean invocations as in this stack:

              Thread [VFSDeploymentScanner]
               InvocationContext.loadClass(String) line: 317
               InvocationContext.getReturnTypeClass() line: 198
               Invocation.getReturnTypeClass() line: 121
               ModelMBeanOperationInterceptor.invoke(Invocation) line: 65
               Invocation.invoke() line: 90
               XMBean(AbstractMBeanInvoker).invoke(String, Object[], String[]) line: 264
               MBeanServerImpl.invoke(ObjectName, String, Object[], String[]) line: 668
               ServiceCreator.installPlainMBean(MBeanServer, ObjectName, ServiceMetaData) line: 199
               ServiceCreator.install(MBeanServer, ObjectName, ServiceMetaData, Object) line: 111
               InstantiateAction.installAction(ServiceControllerContext) line: 45
               InstantiateAction(ServiceControllerContextAction).install(ControllerContext) line: 46
               ServiceControllerContextActions(AbstractControllerContextActions).install(ControllerContext, ControllerState, ControllerState) line: 51
               ServiceControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 226
               ServiceControllerContext.install(ControllerState, ControllerState) line: 187
               AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 596
               AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 346
               AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 438
               AbstractKernelController(AbstractController).resolveContexts(boolean) line: 379
               AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 263
               AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 164
               ServiceController.install(Element, ObjectName) line: 228
               SARDeployer.deploy(DeploymentContext) line: 309
               DeploymentGraphVisitor.visit(Graph<DeploymentContext>, Vertex<DeploymentContext>) line: 74
               Graph<T>.depthFirstSearch(Vertex<T>, VisitorEX<T,E>) line: 225
               MainDeployerImpl.deploy(Deployment) line: 321
               VFSDeploymentScannerImpl.deploy(VirtualFile) line: 608
               VFSDeploymentScannerImpl.scan() line: 520
               VFSDeploymentScannerImpl.run() line: 376
               Executors$RunnableAdapter<T>.call() line: 417
               FutureTask$Sync.innerRunAndReset() line: 280
               ScheduledThreadPoolExecutor$ScheduledFutureTask<V>(FutureTask<V>).runAndReset() line: 135
               ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.access$101(ScheduledThreadPoolExecutor$ScheduledFutureTask) line: 65
               ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.runPeriodic() line: 142
               ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.run() line: 166
               ThreadPoolExecutor$Worker.runTask(Runnable) line: 650
               ThreadPoolExecutor$Worker.run() line: 675
               Thread.run() line: not available
              


              is neither the bean nor SARDeployer class loader. Its the server core org.jboss.system.server.NoAnnotationURLClassLoader, which does not have the jmx classes in the current setup. These are only visible via the JMXClassLoader instance associated with the JMXKernel and SARDeployer beans.

              The VFSClassLoader is not a valid ClassLoadingDomain/DomainClassLoader that can support a unified typesystem currently. This is something I'm going to work on next week while I"m on vacation.

              What I want to do for now is punt and put the jmx class back into the core server loader class loader and spend a couple of hours cleaning up as many SARDeployer issues as I can, and then document the curent state of the VDF impl in the MC_VDF_WORK branch so some progress on porting deployer can be done next week while I'm out.


              • 4. Re: First real SARDeployer porting issue
                starksm64

                It looks ugly with errors about legacy deployers not deploying because they are looking for the obsolete jboss.system:service=MainDeployer, and there are no deployers for rars, wars, but a lot of the legacy services are starting up. I think its a useful starting point for porting the other deployers and services as needed.

                The biggest hack is pushing the jmx classes into the JMXClassLoader bean and associating this with the VFSDeploymentScanner bean. We really need to create a complete class loader aspect and integrated into the VDF. Like I said, I'm going to focus on a rewrite of the VFSClassLoader to incorporate OSGI bundle and JSR277 notions to come up with the next generation unified class loader as the basis for this next week.