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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964657#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...