Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

JNDI look up Advantages?  RSS feed

 
Mohana Murali
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JNDI lookup helps to easy way to get resources hooked and loosely coupled.
Other than this is there any real advantages compared to other approches of JNDI lookup?
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Other approaches of JNDI lookup? I'm not sure what you mean, can you explain?
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you mean alternatives to JNDI lookups, then often there is none. What is important to understand is that all EJBs have a default JNDI context called the environment context. The scope of this context is for all beans from the same home. The default context exists in the name space called "java:comp/env" and its subcontexts. When the bean is deployed, any beans it uses are mapped into the subcontext "java:comp/env/ejb".

Furthermore, The EJB specification recommends that all resource manager connection factory references be organised in the subcontexts of the bean�s environment, using a different subcontext for each resource manager type. So, typically you get this:

java:comp/env/jdbc - for JDBC DataSource references
java:comp/env/jms - for JMS connection factories
java:comp/env/mail - for JavaMail connection factories
java:comp/env/url - for URL connection factories
 
Mohana Murali
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roger, Thanks for reply.

Somewhere in this forum, I read that, using JDNI lookup facilitates using container services. This might be true for EJB. How about JDBC DataSource lookup. Are we still getting some transaction management services from container? Or services comes with JDBC itself. Do we still have advantages of looking up through JNDI?
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
With the example you mention, JNDI really offers nothing more than a mechanism to find a DataSource. It doesn't imply any other container manages services. The normal route to get a DataSource is to look it up in JNDI, but that is not the only way of getting it. What extra services a DataSource includes are implemented by the DataSource provider, and are dependent on the type of DataSource, not the container (if there is one) or JNDI.


Somewhere in this forum, I read that, using JDNI lookup facilitates using container services

Can you link to where you read this? Perhaps we can help more if you can show us the thing your are unsure about?
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think it's transactional as you won't do a JNDI lookup in a transaction.

JDNI lookup facilitates using container services

Every recent EJB Server is compelled by the EJB spec to support the JNDI 1.2 API, and the use of JNDI is integrated with container services.

Let's talk about data sources as it is recommended that JDBC Connections are obtained via a DataSource. It should be noted that sometimes this is compulsory. In WebLogic Server, for instance, external clients must obtain connections through a JDBC data source on the JNDI tree for a cluster. The reason is that the clustered data sources allow a client to request another connection if the server instance hosting the previous connection fails.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!