Programmatically determining ear name for JNDI lookups:

[jnorris10]

When doing JNDI lookups of EJB components (when injection isn't available), I have to lookup by "EAR_NAME/BEAN_IMPL/{local/remote}". However for some components that are shared in different ears, I don't want to hardcode an ear name. Is there a way I find the ear name programmatically?

I realize I can use @LocalBinding/@RemoteBinding to change where it is bound to, but I want it to be bound specifically within the context of the ear since this component could also be deployed in a different ear on the same system. Therefore, representing this context in the JNDI tree by ear name is quite reasonable. I just need to be able to determine the ear name programmatically.

Currently I resort to putting the ear name in a custom configuration file in the EAR, and looking it up when I need to lookup components. However this is clumsy because it's duplicating the implicit ear name information.

[waynebaylor]

you should override the default JNDI names by using the jboss annotations @LocalBinding, @RemoteBinding OR by using the jboss.xml deployment descriptor.

[jnorris10]

"waynebaylor" wrote:
you should override the default JNDI names by using the jboss annotations @LocalBinding, @RemoteBinding OR by using the jboss.xml deployment descriptor.

As I tried to communicate above, I *want* to put these components into JNDI under an ear-like context. I don't want to hard-code another ear-like name into @LocalBinding since this module needs to be a part of multiple ears and therefore have multiple JNDI bindings. I don't want to hard-code it into jboss.xml either since then I have a lot of near-useless configuration details to manage when I put this component into multiple ears.

Currently I put the ear name in a custom configuration file in the EAR, and looking it up when I need to lookup components. However, it would be handy to be able to ask some service what my current ear context name was.

[waynebaylor]

i would recommend that you not include the EAR name at all in your JNDI names. for example, if you have the bean class:

@Stateless
@Local(com.mycomp.MyLocal.class)
@Remote(com.mycomp.MyRemote.class)
public class MyBean implements MyLocal, MyRemote
{
 ...
}

then you should bind its interfaces to meaningful JNDI names (the EAR name can be changed by anyone so it's not meaningful):

@Stateless
@Local(com.mycomp.MyLocal.class)
@Remote(com.mycomp.MyRemote.class)
@LocalBinding(jndiBinding="com.mycomp.MyLocal")
 @RemoteBinding(jndiBinding="com.mycomp.MyRemote")
public class MyBean implements MyLocal, MyRemote
{
 ...
}

As for the multiple EARs part:

1) If you're including it in multiple EARs which will be deployed on the same App. Server, then you will need to include some Class Loading Isolation. You can continue to customize the JNDI name with your config file (i just wouldn't use the EAR name as part of it).

2) If the EARs won't be deployed on the same App. Server, then you won't need the config file anymore.

[jnorris10]

Thanks for your reply. I'm starting to thing that a config file in the ear with a ear-like context name to use for the JNDI root is not such a bad solution.

[wolfc]

Have you tried using ejb-links?

<ejb-local-ref>
 <ejb-ref-name>ejb/myBean</ejb-ref-name>
 <ejb-ref-type>Session</ejb-ref-type>
 <local>com.mycomp.MyLocal</local>
 <ejb-link>MyBean</ejb-link>
</ejb-local-ref>

MyLocal bean = (MyLocal) new InitialContext().lookup("java:comp/env/ejb/myBean");

[jnorris10]

"wolfc" wrote:
Have you tried using ejb-links?

<ejb-local-ref>
 <ejb-ref-name>ejb/myBean</ejb-ref-name>
 <ejb-ref-type>Session</ejb-ref-type>
 <local>com.mycomp.MyLocal</local>
 <ejb-link>MyBean</ejb-link>
</ejb-local-ref>

MyLocal bean = (MyLocal) new InitialContext().lookup("java:comp/env/ejb/myBean");

I don't think I have an ENC in an unmanaged component, do I? Isn't that a managed component concept? I only need to lookup stuff from JNDI for unmanaged components.

[wolfc]

Ah I thought you were talking about doing lookups from components within the EAR. Note that unmanaged components which are used by a managed component can access java:comp/env from that managed component.