>> >> Noticed this part: >> >> [10:21] <sebersole> the problem with osgi is as soon as you ask anyone hat >> that means they have zero clue >> [10:22] <sebersole> "ok you want 'osgi support', how do i do that? what >> does that mean" >> [10:22] <sebersole> and then silence... >> [10:22] <sebersole> thats been my experience at any rate >> >> So my mails about the subject must have been lost or I was not being clear >> on the subject ;) > Which mails? I just searched my local hibernate-dev store for "osgi" > and got zero hits. Perhaps you can point me to them again?
If you want'em, last event I got on it is (there are more but need more time to digg out): February 5, 2009 on hibernate support: just in case you missed it from irc. Here is what toplink/eclipselink used to get their stuff working under osgi. If not to know the details, then maybe use their testcase as a good starting point for verification/debugging. [20:58:09] <|max_at_hibernate|> explanations on what eclipselink had to do [20:58:10] <|max_at_hibernate|> http://wiki.eclipse.org/EclipseLink/Development/OSGi [20:58:26] <|max_at_hibernate|> http://wiki.eclipse.org/EclipseLink/Development/OSGi_Proof_of_Concept I believe those snippets were from an irc chat on hibernate-dev. Anyway, my message on it haven't changed since then ;) > >> "Hibernate osgi support" for me means: Provide an option to use the >> classloader of the calling client/SessionFactory creator instead of >> current thread context classloader; essentially fix all refs to >> ResourceHelper.classForName to always use the classloader of the >> SessionFactory. > This breaks usage in more traditional classloaders. The issue is that > we cannot "always use the classloader of the SessionFactory". We have > to either (1) know the type of environment we are running in (which > afaik is not really possible), or (2) the user must tell us the type of > classloading environment (what class look up schemes should we use). Writing SessionFactory is wrong maybe "persistence-unit-config" is better ? i.e. where the configuration/sessionfactory is built from - we unfortunately don't have a *good* place to store this today. it's somewhere between Configuratio and SessionFactory. > > I assume you mean either ReflectHelper or ConfigHelper. yes, ReflectHelper was what I meant - typing too fast. > ConfigHelper > does not always just look to the TCCL. It tries a number of > classloaders. Yes, from most specific to fallback, provided classloder-> thread context classloader and class.forname which is what will work in SE/JEE. > The problem is that we have to try one or the other > first. And ReflectHelper does allow passing in which classloader to > use. Of course the caller of it must be able to know. Yes. > So lets take an example near and dear to your heart. > org.hibernate.mapping.PersistentClass#getMappedClass > > How do you propose, *specifically*, that method look to work properly in > both osgi environments and traditional classloader environments? The PersistentClass would have to carry the context from where it is created. Possibly simply a ClassLoader which then can be the proper delegate. If the classloader is null it falls back to existing behavior. > Because the only way I see is to use a pluggable delegate for class path > resource resolution. And the problem there is the context of this > delegate (aka how does PersistentClass get access to it?). It would have been created with it. I was actually under the impression that some of the classloader changes done in Annotations/EntityManager were to cover the case in JEE where the classloader at boot/config time isn't properly available to JPA ? It's basically the same situation we have here - but just for many more cases. And yes, this is why it will break some API :) And no, I don't claim to know all the answers to how to fix it - but I know the problem and how I had to go through hoops to "fix" it to use hibernate tools in eclipse (basically embed any call to hibernate with a setThreadContextClassloader call to give it the right context) There are more tricky things in an osgi environment such as how you find the JDBC connection/classes dynamically but I believe we got API to handle that pretty well - the first stopgap is to get classloader's made more explicit and not use ThreadContext class loader first. /max > >> >> That would allow Hibernate to load entities from osgi bundles it does not >> know about via osgi manifest dependencies. >> >> This possibly also requires adding a set of osgi headers to the manifest but >> I don't even think we need to go there (nor can we easily do that because not >> all dependencies we go are available as osgi bundles) >> >> One way to test this is if you can make >> http://dev.eclipse.org/svnroot/rt/org.eclipse.persistence/trunk/examples/org.eclipse.persistence.example.jpa.rcp.comics/ >> >> run with Hibernate jars instead of EclipseLink jars. >> >> EclipseLink guys documented some of their work on this here: >> http://wiki.eclipse.org/EclipseLink/Development/OSGi >> http://wiki.eclipse.org/EclipseLink/Development/OSGi_Proof_of_Concept >> (and others: >> http://wiki.eclipse.org/Special:Search?search=eclipselink+osgi&go=Go) >> >> The guys working on EnterpriseOSGI would also have to solve this somehow so >> maybe it is >> outlined in that area too - I haven't looked deep enough in that yet. > You mean the spec? I have looked briefly and all i really saw was a > bunch of requirements, not any solutions. Perhaps you mean some other > source. > >> >> /max >> >> >> On Apr 19, 2010, at 18:43, Steve Ebersole wrote: >> >>> First meeting. Went well. >>> >>> 1) We discussed our experiences with time-boxing in the 3.5 releases. >>> Generally positive. Some felt 2 weeks may have been a bit too often. >>> We will play with time moving forward to find the best balance which may >>> be an alternation: slow (alphas), fast (betas and crs), slow (past >>> final). >>> >>> 2) 3.6 >>> 2.a) will require at least JDK 1.5 >>> 2.b) merge annotation code into core module >>> 2.c) will revist the idea of merging entitymanager into core module >>> during next meeting. >>> 2.d) specj use case (eagerly loaded key-many-to-one) >>> >>> 3) Hudson plan >>> >>> 4) Documentation consolidation (core, annotations, jbc, envers, >>> entitymanager) >>> >>> 5) docs.jboss.org issues. Archiving release docs versus indexing >>> engines. index.html pages. >>> >>> I have attached the log. >>> >>> -- >>> Steve Ebersole <st...@hibernate.org> >>> http://hibernate.org >>> <meeting-2010-04-19.txt>_______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > > -- > Steve Ebersole <st...@hibernate.org> > http://hibernate.org > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
