<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hi,<br><br>you might be interested that we work on this. We have just created an OSGi Declarative Services component that uses the latest Infinispan-JCache code. Well, this component is pretty primitive, there are only a couple of configuration possibilities:<br>
</div> - Clustername<br></div> - IP<br></div> - Port<br><br></div>The interface of the service that the Component implements has only one function:<br><br></div> - Cache createCache(cacheConfiguration);<br><br></div>cacheConfiguration contains some possibilities like the type (distributed/replicated), maxIdle, maxEntries, ...<br>
<br></div>We had only one problem till now. The infinispan-jcache wired to the javax.enterprise.context and some other packages, although we do not use them in the OSGi world. We made them optional in the MANIFEST.MF and uploaded it to our maven repository.<br>
<br></div>The component will be released very soon (within days) at GitHub. It will be part of our OpenSource framework. Every other components will be able to create caches for themselves based on the cacheFactory component.<br>
<br></div><div>If you are interested, I will keep you up-to-date on this mailing list.<br><br></div><div>Btw.: This is the MANIFEST we use in infinispan-jcache that made everything work (till now) (look for the word "optional" to see what we had to change): <br>
</div><div><br><span style="font-family:courier new,monospace">Import-Package: javax.cache;version="[1.0,2)",javax.cache.annotation;ver
<br> sion="[1.0,2)",javax.cache.configuration,javax.cache.event;version="[1.
<br> 0,2)",javax.cache.expiry,javax.cache.integration,javax.cache.management
<br> ,javax.cache.processor,javax.cache.spi;version="[1.0,2)",javax.enterpri
<br> se.context;resolution:=optional,javax.enterprise.context.spi;resolution
<br> :=optional,javax.enterprise.event;resolution:=optional,javax.enterprise
<br> .inject;resolution:=optional,javax.enterprise.inject.spi;resolution:=op
<br> tional,javax.inject;resolution:=optional,javax.interceptor;resolution:=
<br> optional,javax.management,javax.naming,javax.transaction;version="[1.1,
<br> 2)",javax.transaction.xa;version="[1.1,2)",javax.xml.namespace,org.infi
<br> nispan;version="[6.0,7)",org.infinispan.cdi;resolution:=optional;versio
<br> n="[6.0,7)",org.infinispan.commands;version="[6.0,7)",<a href="http://org.infinispan.co">org.infinispan.co</a>
<br> mmands.read;version="[6.0,7)",org.infinispan.commands.tx;version="[6.0,
<br> 7)",org.infinispan.commons;version="[6.0,7)",org.infinispan.commons.api
<br> ;version="[6.0,7)",org.infinispan.commons.configuration;version="[6.0,7
<br> )",org.infinispan.commons.marshall;version="[6.0,7)",<a href="http://org.infinispan.com">org.infinispan.com</a>
<br> mons.util;version="[6.0,7)",org.infinispan.commons.util.concurrent;vers
<br> ion="[6.0,7)",org.infinispan.configuration.cache;version="[6.0,7)",org.
<br> infinispan.configuration.global;version="[6.0,7)",org.infinispan.config
<br> uration.parsing;version="[6.0,7)",org.infinispan.container;version="[6.
<br> 0,7)",org.infinispan.container.entries;version="[6.0,7)",org.infinispan
<br> .container.versioning;version="[6.0,7)",org.infinispan.context;version=
<br> "[6.0,7)",org.infinispan.factories;version="[6.0,7)",<a href="http://org.infinispan.int">org.infinispan.int</a>
<br> erceptors;version="[6.0,7)",org.infinispan.interceptors.base;version="[
<br> 6.0,7)",org.infinispan.jmx;version="[6.0,7)",org.infinispan.lifecycle;v
<br> ersion="[6.0,7)",org.infinispan.manager;version="[6.0,7)",org.infinispa
<br> n.marshall.core;version="[6.0,7)",org.infinispan.metadata;version="[6.0
<br> ,7)",org.infinispan.notifications;version="[6.0,7)",org.infinispan.noti
<br> fications.cachelistener.annotation;version="[6.0,7)",org.infinispan.not
<br> ifications.cachelistener.event;version="[6.0,7)",org.infinispan.persist
<br> ence.manager;version="[6.0,7)",org.infinispan.persistence.spi;version="
<br> [6.0,7)",org.infinispan.persistence.support;version="[6.0,7)",org.infin
<br> ispan.remoting;version="[6.0,7)",org.infinispan.remoting.transport;vers
<br> ion="[6.0,7)",org.infinispan.remoting.transport.jgroups;version="[6.0,7
<br> )",org.infinispan.stats;version="[6.0,7)",org.infinispan.transaction;ve
<br> rsion="[6.0,7)",org.infinispan.transaction.xa;version="[6.0,7)",org.inf
<br> inispan.transaction.xa.recovery;version="[6.0,7)",org.infinispan.util;v
<br> ersion="[6.0,7)",org.infinispan.util.concurrent;version="[6.0,7)",org.i
<br> nfinispan.util.concurrent.locks.containers;version="[6.0,7)",org.infini
<br> span.util.logging;version="[6.0,7)",org.jboss.logging;version="[3.1,4)"
<br> ,org.jgroups;version="[3.4,4)"</span><br><br></div>Regards,<br><div class="gmail_extra"><br clear="all"><div><div>Balazs Zsoldos</div><div>Software Architect</div><div>Mobile: +36-70/594-92-34</div><div><br>
</div><div>Everit Kft.</div><div><a href="https://www.everit.biz/" target="_blank">https://www.everit.biz</a></div><div><br></div><div>Everit OpenSource</div><div><a href="http://everit.org" target="_blank">http://everit.org</a></div>
</div>
<br><br><div class="gmail_quote">On Fri, Dec 6, 2013 at 4:57 PM, Randall Hauch <span dir="ltr"><<a href="mailto:rhauch@redhat.com" target="_blank">rhauch@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
[1] <a href="http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code.html" target="_blank">http://blog.knowhowlab.org/2010/10/osgi-tutorial-4-ways-to-activate-code.html</a><br>
<div class="HOEnZb"><div class="h5"><br>
On Dec 6, 2013, at 7:30 AM, Mircea Markus <<a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a>> wrote:<br>
<br>
> + infinispan-dev<br>
><br>
> Thanks for offering to look into this Brett!<br>
> 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!<br>
> Tristan can get you up to speed with this.<br>
><br>
><br>
>>> Sanne/Galder/Pete,<br>
>>><br>
>>> 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.<br>
>>><br>
>>> If you're up for it, fill me in? I'm happy to pull everything down and start working with it.<br>
>>><br>
>>> Brett Meyer<br>
>>> Software Engineer<br>
>>> Red Hat, Hibernate ORM<br>
>>><br>
>><br>
><br>
> Cheers,<br>
> --<br>
> Mircea Markus<br>
> Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>