btw. i'm about to go on a roadtrip to DK so won't online much the next couple of days.
I'll try and see if I can create a really simple (eclipse based) example outlining the issue - but otherwise the EclipseLink links and "google hibernate osgi" should give a good set of pointers and "inspiration" :) /max On Apr 20, 2010, at 16:00, Steve Ebersole wrote: > On Tue, 2010-04-20 at 15:28 +0200, Andersen Max wrote: >> Hi, >> >> 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? > >> "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). > > I assume you mean either ReflectHelper or ConfigHelper. ConfigHelper > does not always just look to the TCCL. It tries a number of > classloaders. 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. > > 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? > > 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?). > >> >> 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
