I finally had a chance to start working with this, a bit, today. Here's what I've
found so far.
In general, I'm seeing 2 types of CL issues come up when testing w/
hibernate-infinispan:
1.) Reliance on the client bundle's CL. Take the following stack as an example:
https://gist.github.com/brmeyer/c8aaa1157a4a951a462c. Hibernate's
InfinispanRegionFactory is building a ConfigurationBuilderHolder. Parser60#parseTransport
eventually gives the ConfigurationBuilderHolder#getClassLoader to Util#loadClass. But
since this thread is happening within the hibernate-infinispan bundle, that CL instance is
hibernate-infinispan's BundleWiring. If hibernate-infinispan's manifest
explicitly imports the package being loaded, this works fine. But, as I hit, that's
not usually the case. This stack fails when it attempted to load
org.infinispan.remoting.transport.jgroups.JGroupsTransport. Adding
org.infinispan.remoting.transport.jgroups to our imports worked, but that's not
ideal.
2.) Reliance on TCCL. See GlobalConfigurationBuilder#cl as an example. TCCL should be
avoided at all costs. Here's an example:
https://gist.github.com/brmeyer/141ea83fb632dd126406. Yes, ConfigurationBuilderHolder
could attempt to pass in a CL to GlobalConfigurationBuilder, but we'd run into the
same situation for #1. In this specific example, we're trying to load the
"infinispan-core-component-metadata.dat" resource within the infinispan-core
bundle, not visible to the hibernate-infinispan bundle CL.
commons already has a step towards a solution: OsgiFileLookup. However, it scans over
*all* bundles activated in the container. There's certainly performance issues with
that, but more importantly can introduce conflicts (multiple versions of Infinispan or
client bundles running simultaneously, a resource existing in multiple bundles, etc.).
What we did in Hibernate was to introduce an OSGi-specific implementation of ClassLoader
that's aware of what bundles it needs to consider. In frameworks with multiple
bundles/modules, this is definitely more complicated. For now, we limit the scope to
core, entitymanager (JPA), and the "requesting bundle" (the client bundle
requesting the Session). The "requesting bundle" concept was important for us
since we scan and rely on the client bundle's entities, mapping files, etc.
There are several routes, but all boil down to relying on OSGi APIs to use Bundles to
discover classes and resources, with TCCL & Class#getClassLoader as a just-in-case
backup. How the scope of that Bundle set is defined is largely up to the framework's
existing architecture and dependency tree.
What I might recommend as a first step would be expanding/refactoring OsgiFileLookup to
include loading classes, but continue to allow it to scan all bundles (for now). That
will at least remove the initial CL issues. But, that would need to be followed up.
Before I keep going down the rabbit hole, just wanted to see if there were any other
thoughts. I'm making general assumptions without knowing much about Infinispan's
architecture. Thanks!
Brett Meyer
Red Hat, Hibernate ORM
----- Original Message -----
From: "Brett Meyer" <brmeyer(a)redhat.com>
To: "Randall Hauch" <rhauch(a)redhat.com>, "infinispan -Dev List"
<infinispan-dev(a)lists.jboss.org>
Cc: "Pete Muir" <pmuir(a)redhat.com>, "Steve Jacobs"
<sjacobs(a)redhat.com>
Sent: Friday, December 6, 2013 11:56:42 AM
Subject: Re: [infinispan-dev] help with Infinispan OSGi
Sorry, forgot the link:
[1]
https://hibernate.atlassian.net/browse/HHH-8214
Brett Meyer
Software Engineer
Red Hat, Hibernate ORM
----- Original Message -----
From: "Brett Meyer" <brmeyer(a)redhat.com>
To: "Randall Hauch" <rhauch(a)redhat.com>, "infinispan -Dev List"
<infinispan-dev(a)lists.jboss.org>
Cc: "Pete Muir" <pmuir(a)redhat.com>, "Steve Jacobs"
<sjacobs(a)redhat.com>
Sent: Friday, December 6, 2013 11:51:33 AM
Subject: Re: [infinispan-dev] help with Infinispan OSGi
Randall, that is *definitely* the case and is certainly true for Hibernate. The work
involved:
* correctly resolving ClassLoaders based on the activated bundles
* supporting multiple containers and contexts (container-managed JPA, un-managed
JPA/native, etc.)
* fully supporting OSGi/Blueprint services (both for internal services as well as
externally-registered)
* bundle scanning
* generally working towards supporting the dynamic nature
* full unit-tests with Arquillian and an OSGi container
It's a matter of holistically supporting the "OSGi way" (for better or
worse), as opposed to simply ensuring the library's manifest is correct.
There were a bloody ton of gotchas and caveats I hit along the way. That's more along
the lines of where I might be able to help.
I'm even more interested in this effort so that we can support hibernate-infinispan
2nd level caching within ORM. On the first attempt, I hit ClassLoader issues [1]. Some
of that may already be resolved.
The next step may simply be giving hibernate-infinispan another shot and correcting things
as I find them. In parallel, feel free to let me know if there's anything else! ORM
supports lots of OSGi-enabled extension points, etc. that are powerful for users, but
obviously I don't have the Infinispan knowledge to know what would be necessary.
Thanks!
Brett Meyer
Software Engineer
Red Hat, Hibernate ORM
----- Original Message -----
From: "Randall Hauch" <rhauch(a)redhat.com>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Cc: "Pete Muir" <pmuir(a)redhat.com>, "Brett Meyer"
<brmeyer(a)redhat.com>
Sent: Friday, December 6, 2013 10:57:23 AM
Subject: Re: [infinispan-dev] help with Infinispan OSGi
Brett, correct me if I’m wrong, but isn’t there a difference in making some library *work*
in an OSGi environment and making that library *naturally fit well* in an OSGi-enabled
application? For example, making the JAR’s be OSGi bundles is easy and technically makes
it possible to deploy a JAR into an OSGi env, but that’s not where the payoff is. IIUC
what you really want is a BundleActivator or Declarative Services [1] so that the
library’s components are readily available in a naturally-OSGi way.
[1]
http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code....
On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus(a)redhat.com> wrote:
+ infinispan-dev
Thanks for offering to look into this Brett!
We're already producing OSGi bundles for our modules, but these are not tested
extensively so if you'd review them and test them a bit would be great!
Tristan can get you up to speed with this.
>> Sanne/Galder/Pete,
>>
>> Random question: what's the current state of making Infinispan OSGi friendly?
I'm definitely interested in helping, if it's still a need. This past year, I
went through the exercise of making Hibernate work well in OSGi, so all of challenges
(read: *many* of them) are still fairly fresh on my mind. Plus, I'd love for
hibernate-infinispan to work in OSGi.
>>
>> If you're up for it, fill me in? I'm happy to pull everything down and
start working with it.
>>
>> Brett Meyer
>> Software Engineer
>> Red Hat, Hibernate ORM
>>
>
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev