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: