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" <[email protected]> > To: "Randall Hauch" <[email protected]>, "infinispan -Dev List" > <[email protected]> > Cc: "Pete Muir" <[email protected]>, "Steve Jacobs" <[email protected]> > 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" <[email protected]> > To: "Randall Hauch" <[email protected]>, "infinispan -Dev List" > <[email protected]> > Cc: "Pete Muir" <[email protected]>, "Steve Jacobs" <[email protected]> > 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" <[email protected]> > To: "infinispan -Dev List" <[email protected]> > Cc: "Pete Muir" <[email protected]>, "Brett Meyer" <[email protected]> > 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 <[email protected]> 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 >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
