> 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
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
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
[20:58:09] <|max_at_hibernate|> explanations on what eclipselink had to do
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 ?
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
I assume you mean either ReflectHelper or ConfigHelper.
yes, ReflectHelper was what I meant - typing too fast.
does not always just look to the TCCL. It tries a number of
Yes, from most specific to fallback, provided classloder-> thread context classloader
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.
So lets take an example near and dear to your heart.
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
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
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
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
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.
> 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
> run with Hibernate jars instead of EclipseLink jars.
> EclipseLink guys documented some of their work on this here:
> (and others:
> The guys working on EnterpriseOSGI would also have to solve this somehow so maybe it
> 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
> 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
>> 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,
>> 5) docs.jboss.org
issues. Archiving release docs versus indexing
>> engines. index.html pages.
>> I have attached the log.
>> Steve Ebersole <steve(a)hibernate.org>
>> hibernate-dev mailing list
Steve Ebersole <steve(a)hibernate.org>