java:comp/env question

[Jeroen de Wolf]

The recommended way to call EJBs from a JNDI namespace is to use java:comp/env as a prefix in the lookup. This prefix is appended with a resource reference which can be applied in the ejb deployment descriptor or, in case of a web application calling an EJB, in the web.xml. Suppose you do this from the business layer where there is no deployment descriptor to set the resource reference, yet you still want to use the lookup with the java:comp/env prefix. How can this be achieved?

[JeanLouis Marechaux]

I'm not sure to understand what you mean by "business layer"
You always have access to java:comp/env, 'cause each object is loaded from the Web Container or the EJB container.
So you have access to web.xml or ejb-jar.xml

Could you please tell me what I have missed ?

[Jeroen de Wolf]

The EJB is called from a ServiceLocator which is not part of the EJB jar or the Web, but from a separate (simple java) project.

[JeanLouis Marechaux]

The ServiceLocator is called by a BusinessDelegate (both POJO).
But the BusinessDelegate is instanciated by an object of the web container. So it has access to web.xml properties

[James Carman]

Instead of having your "business layer" lookup the objects, you should "inject" your objects into your business layer object.

 
public class MyBusinessObject
{
  private MyEjbRemoteInterface ejbRemote;
 
  public setEjbRemote( MyEjbRemoteInterface ejbRemote )
  {
    this.ejbRemote = ejbRemote;
  }
 
  public void doSomething()
  {
    ejbRemote.callSomeMethod();
  }
}

This way, you can use this logic anywhere and not have to worry about what "context" you're in (which EJB is topmost on the call stack or which webapp you're in). Also, it makes your business logic easy to test, because you can substitute in mock implementations of your EJB remote interface (this can be done with local interfaces too of course). I would also recommend not using your EJB remote interface in your business layer, but introduce a superinterface into your EJB hierarchy which has the business methods on it. Then, have your EJB remote interface extend your business interface. You could then inject your business interface rather than your EJB remote interface...

  
pubic interface BusinessMethods
{
  public void someBusinessMethod() throws RemoteException;
}
 
public interface MyEjb extends BusinessMethods, EJBObject
{
}
 
public class MyEjbBean implements SessionBean, BusinessMethods 
{
  public void someBusinessMethod()
  {
  }
}

The ugly part here is RemoteException has to be thrown in your BusinessMethods interface, but if you use local interfaces this doesn't happen.