[infinispan-dev] help with Infinispan OSGi

Mon Dec 16 10:08:01 EST 2013

Hi Eric,
thanks that sounds great, having a solid collection of tests is
probably the most usefull specification for what we need to achieve.

@Infinispan team: could we add such tests in the Infinispan
repository? I think that's where they belong.

Sanne

On 16 December 2013 14:00, Eric Wittmann <eric.wittmann at redhat.com> wrote:
> I wanted to add that in the Overlord group we're also looking into using
> ISPN in OSGi.  Our directive is to get our projects running in Fuse 6.1.
>
> To that end I've been working on getting Overlord:S-RAMP up and running,
> which requires both ModeShape and ISPN.
>
> Additionally, Gary Brown uses ISPN in Overlord:RTGov and so will need to get
> it working directly (no ModeShape) in Fuse 6.1.
>
> I've made some progress on my end but have run into some of the same issues
> as Brett.
>
> An additional issue I hit was the use of Java's ServiceLoader for
> org.infinispan.configuration.parsing.ConfigurationParser.  None of the
> parsers get loaded because ServiceLoader doesn't work particularly well in
> OSGi.  We had this same issue in S-RAMP (we use ServiceLoader in a few
> places).  I solved it by using the OSGi Service Registry when running in an
> OSGi container, but continuing to use ServiceLoader otherwise.
>
> In any case - I was wondering if anyone thought it might be a good idea to
> create a git repo where we can create some test OSGi applications that use
> ISPN and can be deployed (e.g. to Fuse).  This would be for testing purposes
> only - to shake out problems.  Might be useful for collaboration?
>
> -Eric
>
>
>
> On 12/12/2013 12:55 PM, Brett Meyer wrote:
>>
>> 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 at redhat.com>
>> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List"
>> <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at 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 at redhat.com>
>> To: "Randall Hauch" <rhauch at redhat.com>, "infinispan -Dev List"
>> <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Steve Jacobs" <sjacobs at 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 at redhat.com>
>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Cc: "Pete Muir" <pmuir at redhat.com>, "Brett Meyer" <brmeyer at 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.html
>>
>> On Dec 6, 2013, at 7:30 AM, Mircea Markus <mmarkus at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>