Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

java:comp/env question  RSS feed

 
Jeroen de Wolf
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Instead of having your "business layer" lookup the objects, you should "inject" your objects into your business layer object.



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...



The ugly part here is RemoteException has to be thrown in your BusinessMethods interface, but if you use local interfaces this doesn't happen.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!