JBossDeveloper

Deeply, current my investigation status is as following:

After I debugged JBOSS 7.1.1.Final(it uses weld-core-1.1.5.AS71.Final),

I found that in org.jboss.weld.bootstrap.Validator class 273,

Set<?> resolvedBeans =

beanManager.getBeanResolver().resolve(beanManager.getBeans(ij));

While ij is "@Inject private

org.infinispan.cdi.AdvancedCacheProducer.defaultCacheContainer",

resolvedBeans is "[Producer Method [EmbeddedCacheManager] with

qualifiers [@Any @Default] declared as [[method] @Produces

@ApplicationScoped public

com.mycompany.Config.defaultEmbeddedCacheManager()]]" and this is right.

However, in  Glassfish 3.1.2.2 (it uses weld-core-1.1.8.Final), the

above resolvedBeans is empty.

That is to say, Glassfish 3.1.2.2 has not found the right Producer

Method from the ear's ejb jar.

Hi,

First, thanks for looking into that :-)

I didn't remember what was my conclusion. I vaguely remember something weird with glassfish CDI injection between two bean archives.

Maybe you can test that by having a producer in a separate bean achive and inject the produced bean in another bean achive ?

Hope this help

Kevin,

Thanks your reply.

Yes, I now am confirm whether in gf, classes in ear's /lib jars with beans.xml can not resolve beans from ear's ejb jar or not?

If being such a case, this should be an *visibility* issue of gf.

CDI injection should allow ear/lib accesses beans from ear's ejb or war.

Thanks

--Tang

Kevin, Kovac

I have made an experiment(a general scene) and confirmed that the same issue happened.

[Reason]

classes in ear's /lib jars with  beans.xml can not resolve beans from ear's ejb jar(maybe war is the same as ejb).

[Conclusion]

This is not related to Infinispan-CDI and Infinispan-Core and should be gf weld integration issue while handling JavaEE Injection.

I have asked gf cdi team to judge whether the issue is bug.

If being a bug, I think that before v4 is released, this should be fixed.

Thanks

--Tang Yong

For glassfish, we need to do a workground by adjusting ear's structure in order to make ear' lib's jar access produce method from another jar.

The attachment has been deployed and ran into glassfish successfully. Pl. seeing it and based on it, you can make an adjustment for your infinispan sample.

Nice :-)

Can you explain the workaround?

Thanks

Hi Kevin,

OK, I want to say the background about glassfish ear deployment,

[Background]

While an user's ear is created with the following structure,

EAR

  |---lib

  |     |----jar1(with beans.xml)

  |     |----jar2(common jar without beans.xml)

  |     |----jar...

  |

  |---ejb(with beans.xml)

This is not an uncommon ear, however, while jar1 has an class which has an inject point,

eg.

jar1:

class A

{

   @inject BInf b      --->BInf is an interface

   ...

}

And ejb has an class which has a produce method to provide a BInf's implementation,

eg.

ejb:

class Ejb

{

    @Produces
    @ApplicationScoped

    public BInf defaultBImpl() {

    ...

    }

}

Then, while deploying such an ear into Glassfish v3.1.2.2, we will see the "WELD-001408 Unsatisfied dependencies".

[Reason]

Glassfish team ever discussed such a similar scene:  whether ear's lib can access ejb or war's classes?

The result is that JavaEE spec has not clearly specified ear's lib must access ejb or war's classes.

About whether the result is reasonable, I think that let us leave the topic to JavaEE spec expert group,

Apparently, Glassfish has not allowed  ear's lib can access ejb or war's classes , so while Weld tries to validate whether having any dependency can

meet " @inject BInf b", although ejb's produce method is there,  "WELD-001408 Unsatisfied dependencies" still happened.

[Extending the background]

If you looked into the infinispan cdi sample with ejb carefully, you will see the sample's design is the same as the above background.

[Workaround]

In theory, I think that three workarounds should be considered,

1. integrate infinispan into Glassfish

As a future consideration, If I have more time, I want to do it, because Infinispan is a greate datagrid framewok and in the future, should be jsr347's RI.

2. make ejb's produce method out of ejb and create a new jar

The attachment from the previous thread is just the solution. Concretely, I create a new ear's structure as following:

EAR(new)

  |---lib

  |     |----jar1(with beans.xml)

  |     |----jar2(common jar without beans.xml)

  |     |----jar3(with beans.xml and having produce method)

  |

  |---ejb(with beans.xml)

jar3 is created for having a produce method to meet jar1's injection point and ejb has removed produce method.

Thus, while deploying the new ear into gf, because jar1 can access jar3, deploying will be successful.

3. put jar1 into ejb

For infinispan's sample, I think that this is not a good solution because, maybe infinispan should be shared with WAR or another EJB.

Of course, if having more solutions, I want to listen to them very much!

Thanks

--Tang Yong

Kovac,

Congratulations!

Tang