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
