In the kernel, we just handle everything through OSGi, which is much more powerful than just self-first / parent-first style delegation.
2009/2/20 jb <[email protected]>: > Thanks for this feedback Guillaume. > > Concerning the classloading issue, maybe it can interested to define a > classloading > policy in the kernel (as we have parent-first/parent-last in application > servers) ? > From a technical point of view, I don't know if it's possible and, for now, > how it can be > implemented, but from an usage point of view, it can be interesting. > > Regards > JB > > On Thursday 19 February 2009 - 08:31, Guillaume Nodet wrote: >> Yesterday, I've been trying to deploy Ode in ServiceMix 4 and found >> some problems. >> >> The first one was the fact that Ode expects the transaction manager to >> implement the >> org.apache.geronimo.transaction.manager.RecoverableTransactionMaanger. >> In order to fix that one (SMX4-51), I've applied the patch attached >> partially (so that the spring proxy for the transaction manager >> actually implement the above interface) and enhanced the JBI URL >> handler to be able to customize the generated manifest header for the >> OSGi bundle created for the JBI component (SMX4NMR-93). Using a >> dynamic import on the above package (or I suppose a plain import) >> works. >> >> The second one was a ClassCastException on a SAX class. For some >> reason, the SAX classes loaded by the JBI component were loaded from >> the JRE instead of the stax-api OSGi bundle. The reason for that one >> is that the first parent of the classloader for the component was the >> system bundle instead of the classloader for the component's bundle. >> I haven't committed the changes yet, but will do it soon. >> >> The last one is caused by the classloader not being able to load >> classes and resources. The exceptions are thrown from the following >> code: >> >> processstoreimp...@24390 daemon, priority=5, in group 'main', status: >> 'RUNNING' >> at >> org.apache.felix.framework.URLHandlersBundleStreamHandler.openConnection(URLHandlersBundleStreamHandler.java:69) >> at java.net.URL.openConnection(URL.java:943) >> at >> sun.net.www.protocol.jar.JarURLConnection.<init>(JarURLConnection.java:64) >> at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:24) >> at java.net.URL.openConnection(URL.java:943) >> at java.net.URL.openStream(URL.java:1,007) >> at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1,216) >> at java.lang.Class.getResourceAsStream(Class.java:1,998) >> at >> org.apache.openjpa.conf.OpenJPAVersion.<clinit>(OpenJPAVersion.java:50) >> at >> org.apache.openjpa.kernel.AbstractBrokerFactory.getFactoryInitializationBanner(AbstractBrokerFactory.java:663) >> at >> org.apache.openjpa.kernel.AbstractBrokerFactory.makeReadOnly(AbstractBrokerFactory.java:616) >> at >> org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:183) >> at >> org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:142) >> at >> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:192) >> at >> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:145) >> at >> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:56) >> at >> org.apache.ode.store.jpa.DbConfStoreConnectionFactory.getConnection(DbConfStoreConnectionFactory.java:49) >> at >> org.apache.ode.store.ProcessStoreImpl.getConnection(ProcessStoreImpl.java:549) >> at >> org.apache.ode.store.ProcessStoreImpl.access$300(ProcessStoreImpl.java:74) >> at >> org.apache.ode.store.ProcessStoreImpl$Callable.call(ProcessStoreImpl.java:698) >> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) >> at java.util.concurrent.FutureTask.run(FutureTask.java:123) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) >> at java.lang.Thread.run(Thread.java:613) >> >> The reason is that the jbi classloader is create with bundle urls >> pointing to the libraries embedded in the component. >> For example: >> bundle://72.0:1/lib/openjpa-1.1.0.jar >> Those URLs are resolved correctly to locate resources, so we end up >> with urls like: >> >> jar:bundle://72.0:1/lib/openjpa-1.1.0.jar!/org/apache/openjpa/kernel/localizer.properties >> Now, the problem is that they fail to be opened at the above point in >> the code. THis is because Felix is trying to find on the stack trace >> a classloader which is of type >> org.apache.felix.framework.searchpolicy.ContentClassLoader (in the >> URLHandlers#getFrameworkContext() method). But there's none because >> all classes are loaded from the JBI component classloader instead of >> a felix classloader in this case. >> >> Anyway, I will try a few things: >> * when transforming the JBI artifact to an OSGi bundle, we could >> leverage the Bundle-Classpath osgi header to point to the embedded >> jars. However, I fear we won't be able to control JBI classloader >> self-first / parent-first delegation when doing so >> * the bundle content is extracted to a folder >> (data/jbi/<name>/install) as required by the JBI spec. We could point >> directly to those files instead of using URLs like bundle:// . >> >> Any other idea is welcome. >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
