As I was composing this email, I solved the problem. However, I don't
understand why to problem occurred. Two things are happening.
1) I (mistakenly?) configured my Context path to be "store" (no
preceding slash) rather than "/store". This makes the difference, in
that "/store" has correctly-behaving JNDI. But what is the difference as
far as Tomcat is concerned? How does Tomcat interpret these two
differently?
2) In the broken "store" configuration, I get the behavior described
below. In a nutshell, I can see that "java:comp/env/jdbc/store" exists
in the tree, but if I try to look it up directly, I get the exception
below. If the app is deployed under "/store", everything is fine. What
gives?
Instinctively, I would feel better if I could turn off the
auto-deployment of webapp directories in Tomcat. Is there a way to do
this?
----------------------------------------------
I recently moved code running on Mac OS X 10.1.5/Java 1.3.1/Tomcat
4.0.4b3 to RH7.2/Java 1.4.0_01/Tomcat 4.0.4. One of the most basic
things I do is get a DataSource from JNDI. On the new installation, this
fails.
I wrote a little Servlet to return the JNDI java:comp tree. Part of its
output is:
> java:comp really does indeed contain:
>
> * "UserTransaction" (java:comp): "org.apache.naming.TransactionRef"
> (org.apache.naming.TransactionRef)
> * "env" (java:comp): "org.apache.naming.NamingContext"
> (org.apache.naming.NamingContext)
> * "jdbc" (env): "org.apache.naming.NamingContext"
> (org.apache.naming.NamingContext)
> * "store" (jdbc): "org.apache.naming.ResourceEnvRef"
> (org.apache.naming.ResourceEnvRef)
You can see that there is something under "java:comp/env/jdbc/store".
However, executing the following code results in a
"javax.naming.NamingException: Cannot create resource instance"
exception.
> Context c = (Context) context.lookup("java:comp/env/jdbc");
> if (c != null)
> {
> out.println("Found jdbc: ");
> Object o = c.lookup("store"); // <--- exception here
> if (o != null)
> {
> out.println("Found store: " + o.getClass().getName());
> }
> else
> {
> out.println("Could not find store");
> }
> }
The server.xml files for the two machines were set up the same, with the
exception that on the working Mac OS X installation, the Context was
based at the doc root, and placed in webapps/ROOT. On the RH7.2 machine
that fails, the Context was based under "store"...
...fixed.
--Rick
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
