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.
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.
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.
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.