Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Works as designed
    • Affects Version/s: 3.1.2
    • Fix Version/s: 4.0
    • Component/s: cdi
    • Labels:
      None
    • Environment:

      Description

      I've attached a sample JEE 6 application that is using Infinispan 5.1.2. The application is working on JBoss 7.1.1, but not on Glassfish 3.1.2.
      It uses:

      • maven as build system
      • Config class to override the default cache manager settings using CDI
      • CacheBean that uses the injected cache manager and work with it
      • Startup bean to put and get some test values from the cache
        When I deploy it to Glassfish I get:
        org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [CacheContainer] with qualifiers [@Default] at injection point [[field] @Inject private org.infinispan.cdi.AdvancedCacheProducer.defaultCacheContainer]
        at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:274)
        at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:243)
        at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:106)
        at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:126)
        at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:345)
        at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:330)
        at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:366)
        at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:199)
        at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
        at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:313)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
        at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
        at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:214)
        at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:207)
        at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:148)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
        at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
        at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
        at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
        at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
        at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
        at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
        at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
        at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
        at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
        at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
        at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
        at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
        at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
        at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
        at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:182)
        at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:147)
        at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:148)
        at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
        at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
        at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
        at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
        at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
        at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
        at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
        at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
        at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
        at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
        at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
        at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
        at java.lang.Thread.run(Thread.java:722)

        Activity

        Hide
        TangYong added a comment -

        Do you confirm the app can work while changing the 5.0.1?

        After I changed the app using 5.0.1.FINAL, although WELD-001408 disappeared, the following exception happened,

        WELD-001409 Ambiguous dependencies for type [EmbeddedCacheManager] with qualifiers [@Default] at injection point [[field] @Inject private com.mycompany.CacheBean.defaultCacheManager]. Possible dependencies [[Producer Method [EmbeddedCacheManager] with qualifiers [@Any @Default] declared as [[method] @Produces @ApplicationScoped public com.mycompany.Config.defaultEmbeddedCacheManager()], Producer Method [EmbeddedCacheManager] with qualifiers [@Any @Default] declared as [[method] @Produces @Default @ApplicationScoped public org.infinispan.cdi.DefaultCacheManagerProducer.getDefaultCacheManager(Instance<EmbeddedCacheManager>, Configuration)]]].

        However, I am also curious why WELD-001408 disappeared.

        Show
        TangYong added a comment - Do you confirm the app can work while changing the 5.0.1? After I changed the app using 5.0.1.FINAL, although WELD-001408 disappeared, the following exception happened, WELD-001409 Ambiguous dependencies for type [EmbeddedCacheManager] with qualifiers [@Default] at injection point [ [field] @Inject private com.mycompany.CacheBean.defaultCacheManager]. Possible dependencies [[Producer Method [EmbeddedCacheManager] with qualifiers [@Any @Default] declared as [ [method] @Produces @ApplicationScoped public com.mycompany.Config.defaultEmbeddedCacheManager()], Producer Method [EmbeddedCacheManager] with qualifiers [@Any @Default] declared as [ [method] @Produces @Default @ApplicationScoped public org.infinispan.cdi.DefaultCacheManagerProducer.getDefaultCacheManager(Instance<EmbeddedCacheManager>, Configuration)]]]. However, I am also curious why WELD-001408 disappeared.
        Hide
        TangYong added a comment -

        Kovica,

        I looked infinispan cdi 5.0.1 source and WELD-001408's disappear is normal and right, because org.infinispan.cdi.DefaultCacheManagerProducer has not any inject point and only produce method, so, for DefaultCacheManagerProducer class, WELD-001408 does not happen, however, because having producing method, this will conflict with ear's sample's produce method.

        Must notice that the WELD-001409 happened while ejb accessed ear's lib jar rather than lib's jar accesses ejb. This is not different from the original scene.

        For glassfish, accessing ear's lib from ejb is allowed.

        So, JJ's comment can be understood.

        Thanks
        --Tang Yong

        Show
        TangYong added a comment - Kovica, I looked infinispan cdi 5.0.1 source and WELD-001408's disappear is normal and right, because org.infinispan.cdi.DefaultCacheManagerProducer has not any inject point and only produce method, so, for DefaultCacheManagerProducer class, WELD-001408 does not happen, however, because having producing method, this will conflict with ear's sample's produce method. Must notice that the WELD-001409 happened while ejb accessed ear's lib jar rather than lib's jar accesses ejb. This is not different from the original scene. For glassfish, accessing ear's lib from ejb is allowed. So, JJ's comment can be understood. Thanks --Tang Yong
        Hide
        kovica added a comment -

        OK, I understand.
        Since this is applciation made by NetBeans using maven based JEE project, how should I change it to make the application work?

        Show
        kovica added a comment - OK, I understand. Since this is applciation made by NetBeans using maven based JEE project, how should I change it to make the application work?
        Hide
        TangYong added a comment -

        In addition, I also found that maybe we will still meet WELD-001409 even if I resolved WELD-001408 by re-adjusting ear's structure. Why?

        If you looked into infinispan-cdi-5.2.1.Final source, you will see DefaultEmbeddedCacheManagerProducer class is still there, thus, while injecting EmbeddedCacheManager for com.mycompany.CacheBean.defaultCacheManager, maybe conflict will happen again.

        Show
        TangYong added a comment - In addition, I also found that maybe we will still meet WELD-001409 even if I resolved WELD-001408 by re-adjusting ear's structure. Why? If you looked into infinispan-cdi-5.2.1.Final source, you will see DefaultEmbeddedCacheManagerProducer class is still there, thus, while injecting EmbeddedCacheManager for com.mycompany.CacheBean.defaultCacheManager, maybe conflict will happen again.
        Hide
        TangYong added a comment - - edited

        A way is that putting infinispan related jars including dependencies into ejb as ejb class path, then, deploying the ear into glassfish. Just as I said above, I worry about WELD-001409, and once this happened, we will discuss again, however, because WELD-001409's scene has been out of the scope of this jira issue, so , please communicate with me by my email(tangyong@cn.fujitsu.com).

        BTW: fixing WELD-001409 can use a customized @Qualifier to qualify your produce method, and use the customized @Qualifier into your sample's injection point.

        Thanks
        --Tang

        Show
        TangYong added a comment - - edited A way is that putting infinispan related jars including dependencies into ejb as ejb class path, then, deploying the ear into glassfish. Just as I said above, I worry about WELD-001409, and once this happened, we will discuss again, however, because WELD-001409's scene has been out of the scope of this jira issue, so , please communicate with me by my email(tangyong@cn.fujitsu.com). BTW: fixing WELD-001409 can use a customized @Qualifier to qualify your produce method, and use the customized @Qualifier into your sample's injection point. Thanks --Tang

          People

          • Assignee:
            jjsnyder83
            Reporter:
            kovica
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: