4 Replies Latest reply on Jul 28, 2010 7:16 AM by Thomas Diesler

    OSGi blocking issue on custom ModuleLoader

    Thomas Diesler Master

      Tracked by MODULES-2

       

      There is currently no way to provide a customized ModuleClassLoader that  uses a delegation model different from what ModuleClassLoader  implements. In OSGi the delegation model is considerably more complex, but can be  implemented by an OSGiModuleClassLoader.

       

      The proposed fix is in http://github.com/jbosgi/jboss-modules/commit/0d2bd8ac9f150455758e18339d9ec5feb013debc

      See 

      * SystemModuleDependencyTest
      * ModuleClassLoaderFactory
      * ModuleSpec

       

      Because this is a blocking issue from the OSGi side, I'd like to continue the discussion here.

      Is there a process we can follow that either accepts or rejects changeset in a practical timeframe?

       

      I track critical issues with the underlying infrastructure in this document: http://bit.ly/aZSpKN

        • 1. Re: OSGi blocking issue on custom ModuleLoader
          Thomas Diesler Master

          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.

          • 2. Re: OSGi blocking issue on custom ModuleLoader
            Thomas Diesler Master

            (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

            • 3. Re: OSGi blocking issue on custom ModuleLoader
              David Lloyd Master

              Thomas Diesler wrote:

               

              (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

               

              Yes, we'd obviously have to add a mechanism to express dependencies on external classloaders that extend ConcurrentClassLoader.

              • 4. Re: OSGi blocking issue on custom ModuleLoader
                Thomas Diesler Master

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

                 

                 

                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

                 

                Screenshot.png

                 

                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.