[infinispan-dev] JCache integration with Wildfly provided configuration

Paul Ferraro paul.ferraro at redhat.com
Tue Aug 18 21:40:03 EDT 2015


I see no reason why your producer wouldn't work - however, JCacheManager.close() will attempt to close the EmbeddedCacheManager.  You shouldn't do that.  The server manages the lifecycle of that resource.

----- Original Message -----
> From: "Christian Beikov" <christian at sweazer.com>
> To: infinispan-dev at lists.jboss.org
> Sent: Monday, August 17, 2015 3:48:11 PM
> Subject: Re: [infinispan-dev] JCache integration with Wildfly	provided	configuration
> 
> Thanks for the quick answer!
> 
> Could you maybe tell me if what I did is ok? So far I don't seem to have
> a problem with the following solution.
> I put my cache configuration into a custom cache container of my
> standalone.xml and inject the cache container just to produce a JSR 107
> CacheManager like that:
> 
> @Singleton
> public class ClusteredCacheManagerProducer {
> 
>      @Resource(lookup = "java:jboss/infinispan/container/app")
>      private EmbeddedCacheManager cacheManager;
> 
>      @Produces
>      @ClusteredCache
>      @ApplicationScoped
>      public CacheManager produceJcacheCacheManager() {
>          return new
> org.infinispan.jcache.JCacheManager(URI.create("app"), cacheManager,
> Caching.getCachingProvider());
>      }
> 
>      public void dispose(@Disposes @ClusteredCache CacheManager
> jcacheManager) {
>          jcacheManager.close();
>      }
> }
> 
> Do you see anything problematic with that approach?
> 
> Regards,
> Christian
> 
> Am 11.08.2015 um 14:29 schrieb Paul Ferraro:
> > ----- Original Message -----
> >> From: "Christian Beikov" <christian at sweazer.com>
> >> To: infinispan-dev at lists.jboss.org
> >> Sent: Sunday, August 9, 2015 12:02:13 PM
> >> Subject: [infinispan-dev] JCache integration with Wildfly provided
> >> 	configuration
> >>
> >> Hello,
> >>
> >> I am using Infinispan 7.2.3.Final within Wildfly 9.0.1 and I would like to
> >> use the JCache integration but I struggle a bit.
> >>
> >> I configured the JGroups subsystem in the standalone.xml of my Wildfly
> >> installation to enable clustering of Infinispan caches. That works as
> >> expected, but I wasn't sure how I would have my caches clustered too. I
> >> thought of some possible solutions but they both aren't really what I am
> >> looking for.
> >>
> >>
> >>      1. Put the cache container configuration into standalone.xml
> >>      2. Copy the JGroups configuration and create a new transport in a
> >>      custom
> >>      infinispan configuration
> >>
> >> When doing 1. I can't really use the JCache integration because there is
> >> no
> >> way to tell the caching provider, that I want a CacheManager for a
> >> specific
> >> cache container. If you would recommend doing 1. then it would be nice if
> >> the caching provider would not only accept file URIs, but also something
> >> like JNDI names. By doing that, I could reference existing cache
> >> containers
> >> which at least solves the problem with the JCache integration. Still I
> >> would
> >> prefer option 2. because I wouldn't have to change the standalone.xml
> >> every
> >> time I add a cache.
> > The trouble with JCache integration into WildFly is that JCache is not an
> > EE spec - and lacks any details for how cache resources should be managed
> > by a container - or how a user would go about accessing container managed
> > caches.  Nor is there any concept of sharing cache resources between
> > applications (i.e. each manages the cache lifecycle manually) - or about
> > isolation of cache entries beyond ClassLoader.  The API itself couples
> > your code to a specific JCache implementation, since the URI of a cache
> > manager is, by nature, provider specific.
> > Consequently, we've deferred integrating JCache into WildFly until it's
> > next evolution (i.e. 1.1/2.0) - or unless it somehow gets pulled into EE8.
> >
> > Consequently, if you really want to use the JCache API, you'll have to
> > stick with option #2 for now.
> >
> >> When doing 2. I can use the infinispan configuration file as URI when
> >> creating the cache manager so the JCache integration works without a
> >> problem. The only thing that is bothering me is, that I have to copy the
> >> JGroups configuration to have a separate transport for my applications
> >> cache
> >> container. I can't seem to reference the transport that I configured in
> >> the
> >> standalone.xml nor does it default to that. I would really like to reuse
> >> the
> >> JGroup channel that is already established.
> > Infinispan requires a separate jgroups channel per cache manager - this is
> > a limitation of Infinispan itself.  The only means of changing this is via
> > a custom Transport implementation (as we do in WildFly).
> > WildFly works around this limitation by providing Infinispan with a unique
> > ForkChannel using a common JChannel.  You might try configuring Infinispan
> > with a custom transport based on the implementation from WildFly.  See:
> > https://github.com/wildfly/wildfly/blob/9.0.1.Final/clustering/infinispan/extension/src/main/java/org/jboss/as/clustering/infinispan/ChannelTransport.java
> >
> >> What I would like to know is, whether there is a possibility to make use
> >> of
> >> the JGroups configuration I did in the standalone.xml. If there isn't,
> >> what
> >> should I do when wanting to cluster my caches? Just go with option 1?
> > Not without customization, see above.
> >
> >> Regards,
> >> Christian Beikov
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 


More information about the infinispan-dev mailing list