Ok, thanks for the clarification Guillaume. Regards JB
On Friday 20 February 2009 - 13:22, Guillaume Nodet wrote: > 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
