Hi Samuel,
To make sure I'm understanding correctly, it looks like what you really want is to perform @EJB injection on objects running inside the container. Is that more or less the high-level goal?
-David
On Feb 10, 2012, at 10:51 AM, Samuel Santos wrote:
> Hi Marina,
>
> Judging from your reply, my text was not clear enough.
> I apologize for that, English is not my first language.
> I will try to exemplify it using code.
>
> Lets say that the project has the following structure:
>
> EAR
> |-- EJBJAR
> | |-- FooService.java
> | `-- FooServiceBean.java
> `-- WAR
> |-- BarActionBean.java
> |-- WEB-INF
> | `-- web.xml
>
> Guessing JNDI names as we do in Stripes Injection Enricher [1] or in JBoss Arquillian [2] will not allow us to inject an EJB in BarActionBean.java like this:
> class BarActionBean {
> @EJB
> FooService fooService;
> }
>
> We must always specify the lookup or mappedName elements of the @EJB annotation:
> class BarActionBean {
> @EJB(lookup = "java:global/EAR/EJBJAR/FooServiceBean!com.foo.bar.FooService")
> // or @EJB(lookup = "java:global/EAR/EJBJAR/FooServiceBean")
> // or @EJB(lookup = "java:app/EJBJAR/FooServiceBean!com.foo.bar.FooService")
> // or @EJB(lookup = "java:app/EJBJAR/FooServiceBean")
> FooService fooService;
> }
>
> What I'm trying to suggest is to have a standard allowing us to configure a project (in this example the WAR archive) to lookup for EJBs in external modules.
>
> Either by defining them in the deployment descriptor:
> <jndi-lookup>
> <modules>
> <module>EJBJAR</module>
> <module>FOOJAR</module>
> <module>BARJAR</module>
> <module>...</module>
> </modules>
> </jndi-lookup>
>
> Or in a properties file (e.g. jndi.properties):
> jndi.lookup.modules=EJBJAR,FOOJAR,BARJAR,...
>
> That way we can read those configurations and lookup for the EJBs in that particular modules without defining the entire JNDI name each time we need to inject an EJB.
>
> [1] https://github.com/samaxes/stripes-injection-enricher/blob/master/src/main/java/com/samaxes/stripes/enricher/EJBInjectionEnricher.java
> [2] https://github.com/arquillian/arquillian-core/blob/master/testenrichers/ejb/src/main/java/org/jboss/arquillian/testenricher/ejb/EJBInjectionEnricher.java
>
> Thank you and best regards,
>
> --
> Samuel Santos
> http://www.samaxes.com/
>
>
> On Fri, Feb 10, 2012 at 2:37 AM, Marina Vatkina <marina.vatkina_at_oracle.com> wrote:
> Samuel,
>
> EJB spec (see 4.4.1.1java:app and 4.4.1.2java:module) is clear that you should use "java:app/ModuleName" to access beans in other modules in your EAR file and "java:module/BeanName" to access beans in the same EJB module.
>
> Best,
> -marina
>
>
> Samuel Santos wrote:
> Hi all,
>
> I find the Global JNDI Namespace, and finally having portable names across different containers, a really neat feature.
> However, it still is not easy to inject EJB from different modules inside an EAR archive.
>
> I'm working on a small open source project [1] to support @EJB, @Inject and @Resource standard Java EE annotations on Stripes Framework [2] using portable JNDI names.
> As you can see by looking at the code [1], I'm using context.lookup("java:app/AppName") and context.lookup("java:module/ModuleName") to build the JNDI names to lookup.
>
> Unfortunately it only works as long as you are injecting EJBs inside the same module where it is.
> If you have an EAR with two modules, one WAR and one EJB, and try to inject an EJB in a class inside the WAR, the code will not work.
> We have to define the full JNDI name in the mappedName or lookup elements of the @EJB annotation every time we are injecting a session bean in a class inside the WAR archive.
>
> I believe it is the role of the EJB spec to make this easier.
> Can we define a way to configure projects to lookup for JNDI names in other modules (e.g. by defining/enumerating them in web.xml or other deployment descriptor)?
>
> [1] https://github.com/samaxes/stripes-injection-enricher/blob/master/src/main/java/com/samaxes/stripes/enricher/EJBInjectionEnricher.java
> [2] http://www.stripesframework.org
>
> Thanks and best regards,
>
> --
> Samuel Santos
> http://www.samaxes.com/
>