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
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?
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?
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.
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
They weren't very bright, but they were very, very big. Ad contrast:
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth