I could not think of a reason why it would not work for you. I tried it in 2 browsers, cause i said i must have signed up or somethin to get acces, but even in the other browser it worked.
I'll copy-paste a little from the page, but there's quite a lot more to be read from the link:
JNDI names look like URLs. A typical name for a database pool is java:comp/env/jdbc/test. The java: scheme is a memory-based tree. comp/env is the standard location for Java configuration objects and
jdbc is the standard location for database pools.
Other URL schemes are allowed as well, including RMI (
rmi://localhost:1099) and LDAP. Many applications, though will stick to the java:comp/env tree.
name meaning
java:comp/env Configuration environment
java:comp/env/jdbc JDBC DataSource pools
java:comp/env/ejb EJB remote home interfaces
java:comp/env/cmp EJB local home interfaces (non-standard)
java:comp/env/jms JMS connection factories
java:comp/env/mail JavaMail connection factories
java:comp/env/url URL connection factories
java:comp/UserTransaction UserTransaction interface
The vast majority of applications will only need the following simple
pattern to lookup objects using JNDI. Since the JNDI objects are typically configured in the web.xml or resin.conf, servlets will typically look up their DataSources or EJB objects once in the init() method. By looking up the object once, the application can avoid any JNDI overhead for normal requests.
Looking up a DataSource
import javax.naming.InitialContext;
import javax.naming.Context;
...
Context env = (Context) new InitialContext().lookup("java:comp/env");
DataSource pool = (DataSource) env.lookup("jdbc/test");
new InitialContext() returns the initial context for the current web-app. As explained above, each application has its own independent JNDI namespace. So applications and virtual hosts will not conflict with each other's JNDI names.
The lookup(subpath) call finds the object at the specified subpath, like a filesystem lookup. Intermediate paths, like env in the example above, are Context objects. There's a strong analogy between filesystem directories and JNDI Context objects.
callmeaning
new InitialContext()A new pointer to the root context
context.lookup("subpath")Finds the object or context at the named path beneath the current context
Applications will generally cache the results of the JNDI lookup. Once configured, factory objects don't change so they can be saved to avoid the JNDI lookup. For example, EJB Home and DataSource factories don't change once they've been configured. A well-designed application will lookup the DataSource once and cache it for the next call. Servlets, for example, will often lookup the DataSource or EJB Home in the init() method and save them in servlet instance variables.
and even more from
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/documents/a1-8-4/Database%20Configuration.faq What is the strange prefix: “java:comp/env”? Why should I apply it when looking up the JDBC data source (SQLJ connection context) in the naming service?
Totally right; with JDBC and SQLJ, J2EE components (executed in the EJB and Web Container) apply the
string “java:comp/env/<resource-reference-name>” when looking up server-side JDBC data sources (database connection pools). For example you could write:
java.sql.DataSource ds = (java.sql.DataSource) jndiCtx.lookup(“java:comp/env/datasourceRef”
;
In doing so, you follow the J2EE recommendation and apply a portable placeholder, the so-called “resource reference,” rather than hard code the actual name of the target database connection pool in your Java code. Actually, the EJB and Web Container learn through the prefix “java:comp/env” that the remaining string suffix (here:”datasourceRef”
is such an abstract resource reference. In the deployment descriptor of affected EJB or web components, you will map the resource reference to the name of the physical connection pool available in the target server installation.
What is the benefit of this redirection? Imagine that your application has been running for a while, but now you decide to move tables keeping application data to another database instance/schema. Marvelous! the name of the database connection pool is not hard-coded in the Java code. The Java code of your J2EE components remains valid; no adjustments or recompiling is necessary. Rather, you have to adjust the mapping in the deployment descriptors and redeploy the application.