cdiinfinispanopen-libertyjcache

CDI exception when trying to use Infinispan JCache on OpenLiberty


I'm trying to use Infinispan and JCache API to add some caching feature tu my JEE app running on OpenLiberty. I'm trying to make it work in a POC project so, for now, I don't have any code, I'm just deploying a war with required dependencies on the app server.

The following features are enabled on OpenLiberty :

<featureManager>
    <feature>jaxrs-2.1</feature>
    <feature>cdi-2.0</feature>
    <feature>mpOpenAPI-2.0</feature>
    <feature>jsonb-1.0</feature>
</featureManager>

I've added those dependencies to my pom :

    <dependency>
        <groupId>org.infinispan</groupId>
        <artifactId>infinispan-core</artifactId>
        <version>14.0.13.Final</version>
    </dependency>
    <dependency>
        <groupId>org.infinispan</groupId>
        <artifactId>infinispan-jcache</artifactId>
        <version>14.0.13.Final</version>
    </dependency>

When I'm starting the server I got the following error :

Stack Dump = org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type CacheResolver with qualifiers @InjectedCacheResolverQualifier
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.infinispan.jcache.annotation.InjectedCacheRemoveEntryInterceptor(@InjectedCacheResolverQualifier CacheResolver, CacheKeyInvocationContextFactory)
  at org.infinispan.jcache.annotation.InjectedCacheRemoveEntryInterceptor.<init>(InjectedCacheRemoveEntryInterceptor.java:0)
WELD-001475: The following beans match by type, but none have matching qualifiers:
  - Managed Bean [class org.infinispan.jcache.annotation.DefaultCacheResolver] with qualifiers [@Any @Default]

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:378)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:290)
    at org.jboss.weld.bootstrap.Validator.validateInterceptor(Validator.java:564)
    at org.jboss.weld.bootstrap.ConcurrentValidator$2.doWork(ConcurrentValidator.java:81)
    at org.jboss.weld.bootstrap.ConcurrentValidator$2.doWork(ConcurrentValidator.java:79)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
    at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    at java.base/java.lang.Thread.run(Thread.java:833)
  1. If I remove the cdi-2.0 feature everything is fine.

  2. If I add the following dependency :

     <dependency>
         <groupId>org.infinispan</groupId>
         <artifactId>infinispan-cdi-embedded</artifactId>
         <version>14.0.13.Final</version>
     </dependency>
    

the error disappear but I still have a worrying warning :

[INFO] [INFOS   ] WELD-001125: Illegal bean type org.infinispan.cdi.embedded.event.AbstractEventBridge<org.infinispan.notifications.cachelistener.event.Event<?, ?>> ignored on [EnhancedAnnotatedTypeImpl] public @Dependent class org.infinispan.cdi.embedded.event.cache.CacheEventBridge

I'm using CDI elsewhere in my application so removing the feature is not an option. It seems that as soon as the environnement support CDI, some magic is happening in Infinispan and it requires 'infinispan-cdi-embedded' to work (why not) but I'm not really confident with the last warning :s


Solution

  • There's no deep magic in infinispan, they have some CDI beans with injection points so if CDI is enabled it will find those beans, try to satisfy the injection points, and fail. With 'infinispan-cdi-embedded' you have what's needed to satisfy the injection points.

    The good news is that you do not need to worry about that message. Weld is saying that is making CacheEventBridge into a bean, but this bean will not list the supertype AbstractEventBridge<Event<?, ?>> as one of its types.

    If you aren't going to use @Inject AbstractEventBridge<Event<?, ?>> this will not be a problem for you.