[infinispan-dev] JCache integration with Wildfly provided configuration

Christian Beikov christian at sweazer.com
Wed Aug 19 05:54:49 EDT 2015


Thanks for that info. Maybe you shouldn't actually close the underlying 
cache manager when managedCacheManager is true?

Am 19.08.2015 um 03:40 schrieb Paul Ferraro:
> 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
>>
> _______________________________________________
> 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