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

[Andersen Max]

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