1 Reply Latest reply on Jan 3, 2012 4:04 AM by Aslak Knutsen

    Cloudbees Container : EJBInjectEnricher issue

    Alexis Hassler Apprentice

      I'm trying to implement my first container in Arquillian. It is a Cloudbees container.


      For the moment, some exemples are working, with CDI ou JAX-RS (as-client).


      I'm facing an issue with the EJBInjectEnricher. It's working fine when I'm specifying the beanName :

      @EJB(beanName="Greeter") Greeter greeter; 

      It does not work with a simple @EJB injection :

      @EJB Greeter greeter; 

      The reason is that the EJBInjectionEnricher uses hard coded ear and war names which aren't compliant with Cloudbees ones. When I deploy an application in Cloudbees, the name of these files are app-deploy.ear and webapp.war. And for a Greeter EJB, the JNDI names are :

      • java:global/app-deploy/webapp/Greeter!org.sewatech.examples.arquillian.ejb.Greeter,
      • java:app/webapp/Greeter!org.sewatech.examples.arquillian.ejb.Greeter,
      • java:module/Greeter!org.sewatech.examples.arquillian.ejb.Greeter,
      • java:global/app-deploy/webapp/Greeter,
      • java:app/webapp/Greeter,
      • java:module/Greeter


      How could I fix that ?

      With a new EJB enricher, I would have to duplicate a lot of code.


      PS1 : my code is here : https://github.com/hasalex/arquillian-container-cloudbees

      PS2 : my example is here : https://github.com/hasalex/arquillian-demo

        • 1. Re: Cloudbees Container : EJBInjectEnricher issue
          Aslak Knutsen Master

          This is a currently limitation of the EJBEnricher. It can't really support 'auto discovery' of JNDI names in a standard way as is.

          The 'solution' is to use mappedName/beanName


          The general problem is, the injection point is refering to the Interface, while the Bean is mapped in JNDI my it's Impl name, and we don't really know the relation. And as you see here, there is no way of getting the name of the app you're deployed in to build a app specific jndi name.


          We have been discussing a workaround for the ejb spec which will basically create a 'fake' EJB of the TestClass and work as a proxy. The FakeTestClass is generated on the fly based on the TestClass, then deployed as a EJB in the container. So when we do the @EJB enrichment of the TestClass, we lookup the FakeTestClass bean and get it's values. Then the individual EJBs should be handled by the Container it self in the same way it normally would. Of course, there is still no standard way of getting to the FakeTestClass beans jndi name, but atleast with EE6 we know the Impl name up front and can use module/FakeTestClass.. I did a 80% impl of this at Devoxx but haven't gotten around to finish it..