1. Using JNDI lookup to access resources Given a resource accessible as request.getServletContext().getResourceAsStream("/some/path/myResource"); it can also be accessed via JNDI (return type is different but equally useful) ic.lookup("java:comp/Resources/some/path/myResource") 2. JNDI lookups ignores aliased resources Given a <Context aliases="/someAlias=/any/path" .../>, its resources are accessible request.getServletContext().getResourceAsStream("/someAlias/myOtherResource"); BUT, the lookup ic.lookup("java:comp/Resources/someAlias/myOtherResource") 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.
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".
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.
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.
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.
Alternative fix applied for 7.0.54.