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

Tue Apr 20 10:53:30 EDT 2010

>> 
>> 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 <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
> 