On Dec 16, 2013, at 4:08 PM, Sanne Grinovero <[email protected]> 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 <[email protected]> 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" <[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 -- Galder Zamarreño [email protected] twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
