At the heart of this issue is the idea to give the ModuleSpec a ModuleClassLoaderFactory, so the Module will use a factory provided CL rather than the default ModuleClassLoader, which is not suitable for OSGi classloading semantics.

(07:48:23 PM) dmlloyd: yes, I see - however the question is, is this the right approach, or does it make more sense to add different kinds of hooks to support the missing functionality in the core, or does it make more sense to say "if modules doesn't fit the use case then OSGi bundles aren't modules" and instead have a mechanism to delegate to arbitrary ConcurrentClassLoaders

If a bundle is not a module, then there is no way to define a module dependency on a bundle. Key of our OSGi effort is the integration of various component models with OSGi and vice versa. Without this objective, we could simply use an existing OSGi Framework bootstrap it in AS and install and run bundles in that isolated world. Please have a look at http://jbossosgi.blogspot.com/2009/06/jboss-osgi-runtime-as-integration.html

Currently, we use two different class loaders that both extend ModuleClassLoader

• FrameworkModuleClassLoader
• OSGiModuleClassLoader

An osgi module always has a dependency on the framework module. The combination of this is targeted to implement osgi class loading semantics.

I took the approach of ModuleClassLoaderFactory because I believe it is least disruptive to the modules layer and gives me the flexibility I need at the osgi layer. Ultimately we need to implemtent this

The current implementation is not yet complete. We don't have support for osgi fragments and native code libraries for example.

A pragmatic approach could be to allow a ModuleClassLoaderFactory for now, so I can have a binary dependency on modules master again. Then you add class loading test cases to modules and try to migrate to ModuleClassLoader extension points rather then client povided ModuleClassLoaders.