Why JNDI ResourceLink not resolved, if .war file name doesn't match context path in Tomcat 5.0.28 ?

[Michael Echerer <me...@tngtech.com>]

Hi,

we have an application that we deploy as .WAR file on Tomcat 5.0.28.
It has a META-INF/context.xml with this content:

<Context path="/foo" reloadable="false" useNaming="true">
	<ResourceLink name="jdbc/myDB" global="jdbc/myDB"
type="javax.sql.DataSource"></ResourceLink>
</Context>

If our .war file is named "foo.war" our JNDI link is properly found, db init ok.
The .war is uncompressed to /foo in webapps and the context path (as seen in
manager app is /foo)

But if we name our .war to "bar.war" our JNDI link does *not* work anymore, if
we still use path="/foo" in the context deployment descriptor in
META-INF/context.xml.

Our .WAR is uncompressed to /bar, because docBase is ignored ihmo anyway (and
the war name is taken), but the context path in the manager app is /foo as it's
set in the context.xml.

I suppose that this is a bug, because I do not see a reason why a ResourceLink
should be visible only if the .war name resp. the webapps dir name match the
deployment descriptor's path. Can anyone confirm this or explain this behaviour
to me?

---

Moreover wouldn't it be a good idea to have the <context>'s "path" attribute
optional when using META-INF/context.xml and use the war file name as default
context path?

Of course, in some cases you might want to explicitely set a context path that
is different from the war name. But it might also be very neat, if one could
simple have an ant script that creates one single war file from the code, you
just rename it as you like, deploy it with the manager app and the whole other
setup is done automatically? Otherwise the ant script always need to replace
the context.xml file according to the war and context path. This is at least
something we would find useful for having multiple contexts for testing on one
machine that you can still simple drop in with the manager app.

Cheers,
Michael






---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org