Re: [infinispan-dev] help with Infinispan OSGi

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(a)redhat.com&gt; 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(a)redhat.com&gt; >> To: "Randall Hauch" <rhauch(a)redhat.com&gt;, "infinispan -Dev List" >> <infinispan-dev(a)lists.jboss.org&gt; >> Cc: "Pete Muir" <pmuir(a)redhat.com&gt;, "Steve Jacobs" <sjacobs(a)redhat.com&gt; >> 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&gt; >> To: "Randall Hauch" <rhauch(a)redhat.com&gt;, "infinispan -Dev List" >> <infinispan-dev(a)lists.jboss.org&gt; >> Cc: "Pete Muir" <pmuir(a)redhat.com&gt;, "Steve Jacobs" <sjacobs(a)redhat.com&gt; >> 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&gt; >> To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org&gt; >> Cc: "Pete Muir" <pmuir(a)redhat.com&gt;, "Brett Meyer" <brmeyer(a)redhat.com&gt; >> 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&gt; 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 >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev