[jboss-user] [JBoss Microcontainer Development] - Wildcard support in Dynamic-imports

Ales Justin do-not-reply at jboss.com
Sat May 15 04:40:05 EDT 2010


Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion

"Wildcard support in Dynamic-imports"

To view the discussion, visit: http://community.jboss.org/message/543228#543228

--------------------------------------------------------------
> I fixed the module tracking issue
>       // Add the modules that can resolve the requirement
>       *for* (Module aux : domain.getModules(null, *null*))
>       {
>          // The wildcard policy should not load from this module
>          *if* (aux == module)
>             *continue*;
>          
>          // Add the module if it can resolve the requirement
>          *if* (aux.canResolve(requirement))
>             modules.add(aux);
>       }
> 
> 
> 
> 
> and the capability resolve issue.
This is not done right, as you're not taking parent order into account.
And the capability issue is a hack, hence it will be removed -- module needs a name.
> 2010-05-15 08:31:19,327 WARN  [org.jboss.detailed.classloader.ClassLoaderManager] Unexpected error during load of:org.jboss.test.osgi.classloader.support.a.A
> java.lang.IllegalStateException: No classloader for this module OSGiModule dynamic-wildcard-c:0.0.0
>     at org.jboss.classloading.spi.dependency.Module.getResource(Module.java:587)
>     at org.jboss.classloading.spi.dependency.policy.WildcardClassLoaderPolicy.findModule(WildcardClassLoaderPolicy.java:113)
>     at org.jboss.classloading.spi.dependency.policy.WildcardClassLoaderPolicy.getBaseClassLoader(WildcardClassLoaderPolicy.java:289)
>     at org.jboss.classloading.spi.dependency.policy.WildcardDelegateLoader.getBaseClassLoader(WildcardDelegateLoader.java:51)
>     at org.jboss.classloader.spi.base.BaseDelegateLoader.getPackage(BaseDelegateLoader.java:160)
>     at org.jboss.classloader.spi.filter.FilteredDelegateLoader.getPackage(FilteredDelegateLoader.java:173)
>     at org.jboss.classloader.spi.base.BaseClassLoaderDomain.getPackageFromImports(BaseClassLoaderDomain.java:1014)
>     at org.jboss.classloader.spi.base.BaseClassLoaderDomain.getPackage(BaseClassLoaderDomain.java:590)
>     at org.jboss.classloader.spi.base.BaseClassLoaderDomain.getPackage(BaseClassLoaderDomain.java:1218)
>     at org.jboss.classloader.spi.base.BaseClassLoader.getPackage(BaseClassLoader.java:262)
>     at org.jboss.classloader.spi.base.BaseClassLoader.definePackage(BaseClassLoader.java:806)
>     at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:645)
>     at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:609)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:608)
>     at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:585)
>     at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:138)
>     at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:461)
>     at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:262)
>     at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:161)
>     at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:262)
>     at org.jboss.osgi.framework.classloading.OSGiClassLoaderDomain.loadClass(OSGiClassLoaderDomain.java:55)
>     at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1164)
>     at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:883)
>     at org.jboss.classloader.spi.base.BaseClassLoader.doLoadClass(BaseClassLoader.java:505)
>     at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:450)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
>     at org.jboss.osgi.framework.bundle.OSGiBundleState.loadClass(OSGiBundleState.java:145)
>     at org.jboss.osgi.framework.bundle.OSGiBundleWrapper.loadClass(OSGiBundleWrapper.java:171)
>     at org.jboss.osgi.testing.OSGiTestHelper.assertLoadClass(OSGiTestHelper.java:278)
>     at org.jboss.osgi.testing.OSGiTest.assertLoadClass(OSGiTest.java:213)
>     at org.jboss.osgi.testing.OSGiFrameworkTest.assertLoadClass(OSGiFrameworkTest.java:193)
>     at org.jboss.test.osgi.classloader.DynamicImportPackageTestCase.testAllPackagesWildcardNotWired(DynamicImportPackageTestCase.java:195)
> 
> 
> This seems to be caused by an issue that the exporting bundle is not RESOLVED. The BaseClassLoaderDomain can find the resource, but when it comes to the actual load the module has no ClassLoader associated. In OSGi a call to Bundle.loadClass() triggers bundle resolution for the exporting module.
> 
> How can we assure that the module transistions to CLASSLOADER stage after the resource was found, but before the class is loaded. Perhaps that should be done in WildcardClassLoaderPolicy when a resource is found in an unresolved module.
I'll add an extra check whether the Module is actually capabale of loading the class.

--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/543228#543228]

Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20100515/7e9429e6/attachment.html 


More information about the jboss-user mailing list