[infinispan-dev] help with Infinispan OSGi
Galder Zamarreño
galder at redhat.com
Wed Dec 18 08:22:47 EST 2013
On Dec 16, 2013, at 4:08 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> 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.
Apart from the quickstart, I agree that some unit tests would be great too and we'd welcome them ;)
>
> 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
>>>
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
More information about the infinispan-dev
mailing list