[ljnelson]

Sorry, Aslak; your workaround suggestion didn't work.

I am looking now at possibly bundling a sun-ejb-jar.xml file and setting the jndi name in there.  Equally dodgy.

Best,

Laird

[aslak]

Just tried the same on JBoss AS 6.0 M3. It works there. They seem to ignore Module name and only use Application Name in the binding.

{code:java}
   @Deployment
   public static EnterpriseArchive createDeployment() {
      JavaArchive ejb = ShrinkWrap.create("blagh.jar", JavaArchive.class)
               .addClasses(
                     GreetingManager.class,
                     GreetingManagerBean.class,
                     InjectionTestCase.class);
      
      return ShrinkWrap.create("test.ear", EnterpriseArchive.class)
               .addModule(ejb);
   }
 

{code}

{code}
20:13:09,709 INFO  [org.jboss.profileservice.management.upload.remoting.DeployHandler] Begin start, [test.ear]
20:13:09,789 INFO  [org.jboss.ejb3.deployers.Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext@224157534{vfs:///home/aslak/dev/servers/jboss-6.0.0.M3/server/default/deploy/test.ear/blagh.jar/}
20:13:09,790 INFO  [org.jboss.ejb3.deployers.Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext@224157534{vfs:///home/aslak/dev/servers/jboss-6.0.0.M3/server/default/deploy/test.ear/blagh.jar/}
20:13:09,791 WARN  [org.jboss.ejb3.interceptor.InterceptorInfoRepository] EJBTHREE-1852: InterceptorInfoRepository is deprecated
20:13:09,811 INFO  [org.jboss.ejb3.deployers.JBossASKernel] Created KernelDeployment for: blagh.jar
20:13:09,811 INFO  [org.jboss.ejb3.deployers.JBossASKernel] installing bean: jboss.j2ee:ear=test.ear,jar=blagh.jar,name=GreetingManagerBean,service=EJB3
20:13:09,811 INFO  [org.jboss.ejb3.deployers.JBossASKernel]   with dependencies:
20:13:09,811 INFO  [org.jboss.ejb3.deployers.JBossASKernel]   and demands:
20:13:09,811 INFO  [org.jboss.ejb3.deployers.JBossASKernel]      jboss.ejb:service=EJBTimerService; Required: Described
20:13:09,812 INFO  [org.jboss.ejb3.deployers.JBossASKernel]   and supplies:
20:13:09,813 INFO  [org.jboss.ejb3.deployers.JBossASKernel]      jndi:GreetingManagerBean
20:13:09,813 INFO  [org.jboss.ejb3.deployers.JBossASKernel]      jndi:test/GreetingManagerBean/local
20:13:09,813 INFO  [org.jboss.ejb3.deployers.JBossASKernel]      jndi:test/GreetingManagerBean/local-com.acme.ejb.GreetingManager
20:13:09,813 INFO  [org.jboss.ejb3.deployers.JBossASKernel]      Class:com.acme.ejb.GreetingManager
20:13:09,813 INFO  [org.jboss.ejb3.deployers.JBossASKernel] Added bean(jboss.j2ee:ear=test.ear,jar=blagh.jar,name=GreetingManagerBean,service=EJB3) to KernelDeployment of: blagh.jar
20:13:09,835 INFO  [org.jboss.ejb3.session.SessionSpecContainer] Starting jboss.j2ee:ear=test.ear,jar=blagh.jar,name=GreetingManagerBean,service=EJB3
20:13:09,835 INFO  [org.jboss.ejb3.EJBContainer] STARTED EJB: com.acme.ejb.GreetingManagerBean ejbName: GreetingManagerBean
20:13:09,837 INFO  [org.jboss.ejb3.proxy.impl.jndiregistrar.JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

     test/GreetingManagerBean/local - EJB3.x Default Local Business Interface
     test/GreetingManagerBean/local-com.acme.ejb.GreetingManager - EJB3.x Local Business Interface

20:13:09,866 INFO  [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/test
20:13:09,907 INFO  [org.jboss.profileservice.management.upload.remoting.DeployHandler] End start, [vfs:///home/aslak/dev/servers/jboss-6.0.0.M3/server/default/deploy/test.ear]
{code}

[aslak]

When looking closer M3 doesn't really follow the EJB 3.1 naming yet it seems..

[dan.j.allen]

This is yet another example of how valuable Arquillian is becoming at testing container compliance. You can't hide anymore, bugs.

[ljnelson]

Aslak: at the time that the EJB enricher runs and does the new InitialContext() creation: is that "over" on the server?  Are the names at that point being run against java:comp/env, or are they being run against a "global" InitialContext?

Nothing I've done in either the ejb-jar.xml or sun-ejb-jar.xml file has seemed to work.  I've got lots of choices, but I realize that I'm not clear on exactly what, for example, a lookup of "test/FooBean/local" would be relative to.  Clearly it doesn't start with "java:global", which is fine, but what I'm not clear on is: is it relative to java:comp/env?

(As you can tell I'm trying to solve the brute force naming problem by NOT trying to make my archive conform to Arquillian's brute force java:global names, but rather by trying to make my archive conform to Arquillian's NON-java:global names.  So far I haven't found a way to get Glassfish to actually honor my jndi-name requests.)

Best,

Laird

[ljnelson]

For others reading this: here's the spec-defined naming syntax that JBoss gets wrong: https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#What_is_the_syntax_for_portable_global_

Best,

Laird

[alrubinger]

Laird Nelson wrote:

For others reading this: here's the spec-defined naming syntax that JBoss gets wrong: https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#What_is_the_syntax_for_portable_global_

Wrong != Unimplemented.

We're not yet fully EJB 3.1 compliant.

S,

ALR

[ljnelson]

Fair enough; thought it was defined by EJB 3.0...?  I am probably misremembering.  Sorry to assign blame where it wasn't appropriate!

Best,

Laird

[aslak]

Laird Nelson wrote:

Aslak: at the time that the EJB enricher runs and does the new InitialContext() creation: is that "over" on the server?  Are the names at that point being run against java:comp/env, or are they being run against a "global" InitialContext?

It's on the server side yes. test/name is relative to root, not comp

[ljnelson]

Holy mother of God, I found a workaround.

Some of this sounds like things that Arquillian is going to have to be aware of.  They may also be things that I am simply ignorant of.

Background: I am testing an Enterprise Archive with a single EJB jar in it.  Arquillian can't find my EJB in there under any of its hardcoded JNDI names.

First off, it looks like if you could simply rename test.war to arquillian-test-machinery.war with a context root of "/test" everything will go back to normal.

But, to the workaround at hand.

It looks like Arquillian's test.war file eats up the "test" module name space.  That is, no matter what I try, test.war gets a module name of "test".  So that means that my test.jar, no matter what I do with deployment descriptors and the like, will never have a module name of "test", because Glassfish silently turns it into "testejb", even when I explicitly set its module-name to "test".

THAT rules out getting at my EJB via "java:global/test..." names for the time being until Arquillian is changed, because none of the hard coded global JNDI names that Arquillian tries includes "testejb".

Arquillian then falls back and tries several "relative" JNDI names, like, for example, "test/FooBean/local" and "test/FooBean/remote" (there are others).  So my challenge was: could I get my bean mapped under one of these names instead?

I can, but it requires that my bean have a @Remote interface view, because Glassfish disallows global JNDI names for non-remote beans.  See https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#SessionBeanGlobalJNDINameAssignment for details.  In the case of local beans, it appears to my very very very tired eyes like Glassfish assigns a name to them, but they are still not reachable outside of the container.

Anyhow, so in my ejb-jar.xml I specify a <mapped-name> of test/FooBean/remote, and I make sure that my bean has a remote view.  For the time being this will work, but I sure don't actually want this bean to have a remote view going forwards.

The piece I find interesting is: is my Arquillian test that is undergoing injection outside of the container?  Because it sure looks like I can't get a handle on my EJB unless it is a local bean.

Best,

Laird

[aslak]

Another workaround is to trigger the CDIInjectionEnricher in Arquillian. This is triggered if it can find a BeanManager in JNDI. This enricher use CDI to do the injection and CDI has a hook into the container for the @EJB/@Resource lookup. You can 'force' a BeanManager creation during deploy even if you don't use any CDI features by adding a empty beans.xml to one of your EE Modules. In your case this would be your EJB jar.

{code:java}
   @Deployment
   public static EnterpriseArchive createDeployment() {
      JavaArchive ejb = ShrinkWrap.create("blagh.jar", JavaArchive.class)
               .addClasses(
                     GreetingManager.class,
                     GreetingManagerBean.class,
                     InjectionTestCase.class)
               .addManifestResource(
                     new ByteArrayAsset("<beans/>".getBytes()),
                     ArchivePaths.create("beans.xml"));
 
      return ShrinkWrap.create("test.ear", EnterpriseArchive.class)
               .addModule(ejb);
   }

{code}

This only works reliable in Arquillian trunk. The order of the Enrichers are executed randomly in Alpha-2. In trunk they now execute in the defined order by the Contianer, which is CDI, EJB then Resources. The EJB and Resource enrichers will ignore fields that are already set(in this case set by the CDI enricher).

-aslak-