-
1. Re: OSGi blocking issue on custom ModuleLoader
thomas.diesler Jul 27, 2010 7:45 PM (in response to thomas.diesler)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 Jul 27, 2010 8:28 PM (in response to thomas.diesler)(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
dmlloyd Jul 27, 2010 9:00 PM (in response to thomas.diesler)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 Jul 28, 2010 7:16 AM (in response to dmlloyd)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
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.