The issues you face are mainly an issue of Hibernate. Hibernate just rebuilds it's own classloader, which works as long as you have a hierarchical classloader but is a real PITA in a graph-like classloader as used in OSGi. Regarding the library nightmare I have to say I don't see you point, it's even worse in classic classloader containers. If on drops a certain version of a library in the "endoresed" folder of the container all applications have to use that one jar, since in those classloaders it's always first come, first serve. At the end you always end up with a big monolithic deployment junk (aka EAR), where all the modularity you thought of while developing is gone.
When using OSGi you should try to think more of services and use those services. This also helps a lot with dependencies. :) just my 2 cents here, Achim 2013/1/29 Gonzalo Aguilar <[email protected]> > Bram Pouwelse wrote > > I've used Hibernate in Karaf in the past got it al working based on on > > Hibernate bundles created as described in this blog post: > > > http://iocanel.blogspot.nl/2010/07/wicket-spring-3-jpa2-hibernate-osgi.html > > > > I was able to update these bundles to Hibernate 3.6.2 but switched to > > OpenJPA after all. > > Yes! I have this guy in my bookmark. Ioannis... I have the project but I > found that he uses maven-jar-plugin to create the bundles something that I > think is not necessary. > > I'm able to create the bundle, I used the blog to do it, that's not the > problem. The problem is that it does there is class loader problems if you > try to update. I'm on hibernate 3.6.10.Final and spring 3.0.7.RELEASE but's > something I don't really catch that is causing me headaches. > > This packages works well in tomcat for example, no issues there... so there > is something, I say, that I'm issing. > > I think I'll take a look to the solutions exposed. Will try to build > completly the project of Ioannis, but I surely will go with traditional > Tomcat aproach until the project is somewhat more stable. > > But will keep an eye on it. :D > > > What I resolved asking here is that I'm not the only one having this kind > of > problems. > > I have to say that this "library nightmare" is resolved in traditional > environments just installing and removing library versions that does not > much. You don't have to repackage anything. > > So where is the advantage of OSGi. I really don't see it. > > I have to say that evangelists of OSGi always say that it's a good > provisioning system. But the most commonly program I know built on OSGi is > Eclipse, and I have to say that I have to remove the whole plugin pack if I > make an error with installed versions of the plugins. Because it will not > work! > > So again, I don't see the advantage. > > I want to build on OSGi, because it seems to be an isolated VM that can do > anything. With the cellar project it looks promissing. But not because the > library handling, it's because seems to be well done. > > Let's see the future. Blueprint and iPOJO came to ease the bundle > construction. I hope something arises that will help to distribute > libraries > in the way are packaged right now. > > > Thank you again. > > > > -- > View this message in context: > http://karaf.922171.n3.nabble.com/Why-this-library-hell-Hibernate-Spring-Mess-tp4027506p4027514.html > Sent from the Karaf - User mailing list archive at Nabble.com. > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
