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(a)sweazer.com>
> To: infinispan-dev(a)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(a)sweazer.com>
>>> To: infinispan-dev(a)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...
>>
>>> 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(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev