No I haven't changed my view. The MC doesn't favour a specific classloader implementation. It is left to the configuration how you create classloaders and what type they are. There are some basic rules that need to be followed to work with what the other deployers expect. e.g. * support hierarchical domains/repositories * switching from j2se classloading compliance * delegation to peer classloaders * allowing specific imports and versioning for OSGi style deployments * (in future) filtering out certain packages, etc. All these are encapsulated by the ClassLoaderMetaData. If the classloader doesn't support these notions, (e.g. the old UCL doesn't support OSGi version rules) then those deployments won't work as expected. We could add validation to the legacy ServiceClassLoaderDeployer that creates the old UCLs to spot when it cannot support the new features, but in practice we'll probably just drop support for this old classloader implementation. So, in summary, I don't see a need to tightly integrate the classloader with the MC. The question is only whether your choice of classloader implementation can support all the features requested by the other deployers via the ClassLoaderMetadata. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124846#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...