Bug 56451 - JNDI lookups under java:comp/Resources do not access <Context aliases> resources
Summary: JNDI lookups under java:comp/Resources do not access <Context aliases> resources
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 7.0.47
Hardware: PC Linux
: P2 minor (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2014-04-24 00:53 UTC by C. Daniel MOJOLI BOGGINO
Modified: 2014-05-07 13:17 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description C. Daniel MOJOLI BOGGINO 2014-04-24 00:53:12 UTC
1. Using JNDI lookup to access resources

Given a resource accessible as


it can also be accessed via JNDI (return type is different but equally useful)


2. JNDI lookups ignores aliased resources

Given a <Context aliases="/someAlias=/any/path" .../>, its resources are accessible


BUT, the lookup 

fails throwing org.apache.naming.resources.ImmutableNameNotFoundException.

Listing the java:comp/Resources context shows someAlias is NOT bound.

3. Expected behavior

Tomcat exposes resources under the java:comp/Resources JNDI context. Aliases should also apply to this alternate access interface.
Comment 1 Konstantin Kolinko 2014-04-25 17:15:33 UTC
1. Note that this API is not available in Tomcat 8,
but you can call

> ic.lookup("java:comp/Resources")

which will return StandardRoot.

2. Debugging Tomcat 7, the cause for this issue is different from what I expected.

> ic.lookup("java:comp/Resources")

In Tomcat 7 is an instance of ProxyDirContext.

If use the OP way,
- The string name is parsed into CompositeName.
- There is a series of lookups, each obtaining a org.apache.naming.NamingContext and looking up the name with first component removed.  See NamingContext.lookup(Name, boolean resolveLinks:= true)
{ ... return ((Context) entry.value).lookup(name.getSuffix(1)) }
- It goes into ProxyDirContext.lookup(Name)
- It does cacheLookup(name.toString())
- The cacheLookup method creates CacheEntry and calls cacheLoad() to fill it.
- The cacheLoad method calls dirContext.getAttributes(entry.name).

The problem is that
1) name.toString() looks like "some/path/myResource"
2) when you call resource lookup the name will be "/some/path/myResource" with leading "/".

This results in
- Aliases in BaseDirContext/FileDirContext do not work, as all aliases start with leading "/".
- Inconsistency in cache keys in ProxyDirContext.

I wonder whether this is better be fixed by consistently adding '/' to the start of the string, or by consistently removing starting '/'
from names and aliases.

The latter will be more effective (substring is cheaper that string concatenation), and more correct from JNDI API point of view,
but it may be easy to miss some use case.

It is also possible to say that this is unsupported API and close as wontfix.

Note that the following works correctly:
((Context) ic.lookup("java:comp/Resources").lookup("/someAlias/myOtherResource")

Note leading "/" in "/someAlias".
Comment 2 Mark Thomas 2014-05-02 21:55:24 UTC
This has been fixed in trunk for 7.0.54 onwards.

Note: A JNDI name with a leading '/' should be interpreted as having any empty first name part which never makes sense in this case. Therefore, I opted to remove / from the alias path before adding to the aliases map.
Comment 3 Konstantin Kolinko 2014-05-02 22:15:01 UTC
Re r1592052

I am sure that that is not enough.

There are calls to ProxyDirContext.lookupCache(str) in DefaultServlet, WebdavSevlet.

There are calls to contextVersion.resources.lookup(str) in Mapper.

All they are using Servlet resource path (starting with '/') instead of JNDI name, and I think they are now broken.
Comment 4 Mark Thomas 2014-05-06 12:16:42 UTC
I'm looking at this now. It appears that directory listings aren't handled correctly for aliases either (and don't appear to have been correct before r1592052 either.
Comment 5 Mark Thomas 2014-05-07 13:17:40 UTC
Alternative fix applied for 7.0.54.