How to call an EJB in one EAR from another EAR in the same server?

[kieras1]

Dear Community,

I have two EAR application deployed in the same JBoss AS EAP 6.

On the first EAR (myapp1.ear) I have an EJB module (myejb.jar) with one Staless EJB (MyBusinessFacade) that implements a remote facade ("MyBusinessFacadeRemote").

On the second EAR (myapp2.ear) I have an WAR module (mywebapp.war) with a JSF managed bean (MyControl).

I want "MyControl" calls methods on "MyBusinessFacade" through "MyBusinessFacadeRemote".

The only way I could get it working (ie. locate the EJB correctly) was using the "lookup" attribute of the @EJB annotation and passing the global JNDI name of "MyBusinessFacadeRemote". The code on "MyControl" looks like:

public class MyControl {

    @EJB(lookup = "java:global/myapp1/myejb/MyBusinessFacade!com.mycompany.business.MyBusinessFacadeRemote")

    private MyBusinessFacadeRemote facade;

    ...

It is working fine, but the lookup string is fixed in the code.

Here is my question:

Is there any way I could call that EJB without putting that string fixed in my code?

Ideally I wanted it could be just annotated with @EJB, and no parameters. :-)

Thanks!

[nickarls]

You might be able to shuffle around the location but I guess the information has to be somewhere...

[kieras1]

I see... You're right.

Maybe I just didn't want to believe.

Thank you very much, Nicklas!

[erhard]

I came across the same problem. What I don't like on the global jndi-name is, that it is not refactoring friendly. The solution I came across is the following:

On the service-side I annotate the EJB with

@Resources( {

@Resource(name="java:/services/StringConverter", lookup="java:module/ConverterBean"),

})

@Stateless

@Remote(StringConverter.class)

public class ConverterBean implements StringConverter{...}

On the client side I inject:

@EJB(mappedName="java:/services/StringConverter")

StringConverter svc1;

Full example on https://github.com/Gepardec/jboss-examples/tree/master/call-ejb-between-deployments

Still not perfect, but probably better. We do have many EJBs in one big EAR that I want to take apart, so every improvement is welcome.