[hibernate-dev] Weekly meeting (4/19)

[Steve Ebersole]

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 <steve at hibernate.org>
> > http://hibernate.org
> > <meeting-2010-04-19.txt>_______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 


-- 
Steve Ebersole <steve at hibernate.org>
http://hibernate.org