This question already has answers here:
What does java:comp/env/ do?
(3 answers)
Closed 2 years ago.
what is meant by java:comp/env ?
What does the look up like :
Context envContext = (Context)initContext.lookup("java:comp/env");
do ?
I understand that a look-up like :
(DataSource)envContext.lookup("jdbc/MyDatasource")
looks up for the name MyDatasource in the context.xml or web.xml to get the URL of the database. Is it so ? !! But what does the former look up do ?
java:comp/env is the node in the JNDI tree where you can find properties for the current Java EE component (a webapp, or an EJB).
Context envContext = (Context)initContext.lookup("java:comp/env");
allows defining a variable pointing directly to this node. It allows doing
SomeBean s = (SomeBean) envContext.lookup("ejb/someBean");
DataSource ds = (DataSource) envContext.lookup("jdbc/dataSource");
rather than
SomeBean s = (SomeBean) initContext.lookup("java:comp/env/ejb/someBean");
DataSource ds = (DataSource) initContext.lookup("java:comp/env/jdbc/dataSource");
Relative paths instead of absolute paths. That's what it's used for.
It's an in-memory global hashtable where you can store global variables by name.
The "java:" url scheme causes JNDI to look for a javaURLContextFactory class, which is usually provided by your app container, e.g. here is Tomcat's implementation javadoc
See also NamingManager.getURLContext
I know I'm far late, but I was asking the same question, and I think I came some answer. So, if I may put my two cents.
java:comp/env/jdbc/myDataSource
java: is just like jdbc: from connection string. Acts as a protocol.
comp is the root for all JNDI contexts.
env is the subcontext for all resource related. There is another for user. Check this out.
jdbc is the subcontext for jdbc resources. There are types. Check the link from the previous bullet.
myDataSource is the name of your jdbc resource.
Related
I am new to Java EE world, in my application I would like to connect to the Database. I was able to accomplish this task with the code below, but can someone explains it to me? What each line does?
code:
try {
InitialContext initContext = new InitialContext();
Context env = (Context) initContext.lookup("java:comp/env");
ds = (DataSource) env.lookup("jdbc/test2");
} catch (NamingException e) {
throw new ServletException();
}
I also found out that I can use the annotation below in my JSP using tomcat which accomplish the same result as above. Can I use this annotation with any web server, ex GlassFish or Jboos ?
Anotation code:
#Resource(name = "jdbc/test2")
private DataSource ds;
The Java Naming and Directory Interface™ (JNDI) is an application
programming interface (API) that provides naming and directory
functionality to applications written using the Java™ programming
language. 1
The Context object provides the methods for binding names to objects, unbinding names from objects, renaming objects and listing the bindings.
JDNI performs all naming operations relative to a context. Therefore the JDNI defines an InitialContext, which provides a starting point for naming and directory operations. Once you have an initial context, you can use it to look up other contexts and objects.
Many methods in the JDNI package throw a NamingException when they need to indicate that the operation requested cannot be performed. The JDNI has a rich exception hierarchy stemming from the NamingException class. The class names of the exceptions are self-explanatory and are listed here.
You can use the #Resource annotation to inject resources. You can find more information on the correct use here.
Sources:
https://docs.oracle.com/javase/tutorial/jndi/overview/index.html
http://www.javaworld.com/article/2076888/core-java/jndi-overview--part-1--an-introduction-to-naming-services.html
I saw a stackoverflow answer to a question on JNDI.
The answer showed a few lines of code using InitialContext to retrieve a DataSource.
However, the instance of InitialContext was not created with any properties to use any sort of service such as LDAP or the file system.
Where does the entry go when you bind it to an InitialContext with the null constructor ?
Will the entry only visible within the application ?
Will it not persist when you shutdown the application ?
Where does the entry go when you bind it to an InitialContext with the null constructor?
If there is a resource file named /jndi.properties it uses whatever environment is defined in there. Servlet containers typically use this to define an extra object factory for the java: namespace.
Will the entry only [be] visible within the application?
Yes.
Will it not persist when you shutdown the application?
It will not persist unless the container implements that.
I have a web application trying to access a JNDI declared in WebSphere Application Server.
The JNDI is declared under Object pool managers. However, I'm receiving an error when I access the pool. The error says that comp/env/pool is not found in context "java:".
My code is written as follows:
InitialContext initialContext = new InitialContext();
ObjectPoolManager opm = (ObjectPoolManager)initialContext.lookup("java:comp/env/pool");
Accessing the pool via the code below works:
ObjectPoolManager opm = (ObjectPoolManager)initialContext.lookup("pool");
I'm confused because according to what I've found on the internet, java:comp/env/ is a default prefix for JNDI. So why does it cause an error in my case?
Thank you!
you can only use java:comp/env if you have declared a reference to the Object Pool in your web.xml under the resource-ref section.
See What is resource-ref in web.xml used for? for further explanation.
"javax.naming.Context" is commonly used inside Java EE development. It's quite convenient to use it to establish dynamical database connection by calling its lookup function with given names of resources inside context.xml. The sample code is shown as following where "db_name" is the name you used to identify the database resource.
Context ctx = new InitialContext();
DataSource ds = ctx.lookup("java:comp/env/jdbc/db_name");
My concern is what are the differences between lookup resources by using the same context and lookup resources by using different contexts. And which approach makes more sense or suitable? Suppose all database resources are defined inside the same context.xml file. For example:
Context ctx = new InitialContext();
DataSource ds1 = ctx.lookup("java:comp/env/jdbc/db_name_ds1");
DataSource ds2 = ctx.lookup("java:comp/env/jdbc/db_name_ds2");
and
Context ctx_ds1 = new InitialContext();
Context ctx_ds2 = new InitialContext();
DataSource ds1 = ctx_ds1.lookup("java:comp/env/jdbc/db_name_ds1");
DataSource ds2 = ctx_ds2.lookup("java:comp/env/jdbc/db_name_ds2");
Thank you for your sharing.
there is no difference except you created an unnecessary extra java object. however, if the jndi server was remote, you would have created two different network connections and iverhead of managing them - definetly not what one should do.
I'm using a Connection via severals pools :
DataSource ds = initialContext.lookup("poolname1");
Connection cn = ds.getConnection();
submethod1(cn);
submethod2(cn);
void submethod1(Connection cn)
{
// using connection
// ..
}
My question is: how to log "poolname" in submethods ? or similar informations about DataSource.
Perhaps this will help
getClientInfo()
or
getMetaData()
as mentionned in the Official Java Doc
The poolname in your example is actually a JNDI Name. This is generally a configuration which is configured in resource definition (e.q under in tomcat config).
For your problem as #sourlcheck mentioned, its not possible as connection are not aware of their datasource.
Once way to solve your problem is to give label to the datasource. Most of the Pooled datasource implementations (e.q. C3P0) offer a setter for setting up a name to the datasource. In C3P0 the datasournce class is ComboPooledDataSource and the method is getDataSourceName(). Once you get this name, it remains the same throughout its life cycle. But off course you need to introduce third party library
You can't log "poolname" in methods that receive Connection. Connections don't know if they are pooled or served directly from non-pooling DataSource.
Also you can create and access your pool in many different ways, not all of them guaranteeing existence of "poolname".