Bug 59255 - 404 due to NullPointer in Mapper.java
Summary: 404 due to NullPointer in Mapper.java
Alias: None
Product: Tomcat 8
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 8.0.29
Hardware: PC Linux
: P2 major (vote)
Target Milestone: ----
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2016-03-31 11:11 UTC by mmikolajczyk
Modified: 2019-12-30 10:34 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description mmikolajczyk 2016-03-31 11:11:06 UTC
Since update to Tomcat 8.0.29 we noticed problems in our Struts based application. Some actions in random moments returned 404 errors without any log. The same problem appeared in 8.0.30-33. We analyzed changes made between versions 8.0.28 and 8.0.29 and by adding them one by one we found that the problem is caused by org.apache.catalina.mapper.Mapper and new properties in Context: mapperContextRootRedirectEnabled and mapperDirectoryRedirectEnabled. mappingData.context.getMapper...RedirectEnabled() throws in some situations null pointer exception because mappingData.context in null. 

After changing code of Mapper.java in Tomcat 8.0.33 and recompiling we confirmed that
<         if(mappingData.wrapper == null && noServletPath) {
>       if (mappingData.wrapper == null && noServletPath && mappingData.context == null){
>               log.error("Kaboom:  " + mappingData.toString());
>       } else {
>         if(mappingData.wrapper == null && noServletPath &&
>                 mappingData.context.getMapperContextRootRedirectEnabled()) {
>       }
<                 if (file != null && file.isDirectory()) {
>               if (file != null && file.isDirectory() && mappingData.context == null){
>                       log.error("Kaboom:   " + mappingData.toString());
>               } else {
>                 if (file != null && file.isDirectory() &&
>                         mappingData.context.getMapperDirectoryRedirectEnabled()) {
>               }

logs in catalina.out:
31-Mar-2016 10:23:28.633 SEVERE [ajp-nio-] org.apache.catalina.mapper.Mapper.internalMapWrapper Kaboom:   org.apache.catalina.mapper.MappingData@6443d97d
31-Mar-2016 10:24:40.946 SEVERE [ajp-nio-] org.apache.catalina.mapper.Mapper.internalMapWrapper Kaboom:   org.apache.catalina.mapper.MappingData@6443d97d
31-Mar-2016 10:25:26.272 SEVERE [ajp-nio-] org.apache.catalina.mapper.Mapper.internalMapWrapper Kaboom:   org.apache.catalina.mapper.MappingData@14a421a8

If there is anything that we can do to help you solve this problem please send us information how we can help.
Comment 1 Remy Maucherat 2016-03-31 14:55:37 UTC
Certainly this sort of occurrence is not going to be logged. Besides concurrent recycling, I don't really see what could cause it as mappingData.context is set right before calling internalMapWrapper, so it's really something that is up to you to debug.

IMO this should be INVALID until you demonstrate some reasonably legitimate course of action that leads to the NPE.
Comment 2 Konstantin Kolinko 2016-03-31 15:36:14 UTC
1. Sample configuration / steps to reproduce the issue = ?

2. Diffs are preferred in Unified Diff format
Comment 3 Konstantin Kolinko 2016-03-31 15:45:02 UTC
Looking at 8.0.x Mapper.java, I think that in both mentioned places


has be replaced with obtaining the context from ContextVersion object. Both places have it, so I see no reason why context is retrieved from mappingData.

A test case is TBD.
Comment 4 Remy Maucherat 2016-03-31 16:00:03 UTC
Ok, so mappingData.context -> contextVersion.object. No problem.

Since I don't see how mappingData.context becomes null, mappingData.wrapper probably also gets reset as well which will randomly mess up the mapping algorithm.
Comment 5 Remy Maucherat 2016-03-31 19:25:38 UTC
Ok, I applied this for 9M5, 8.5.1, 8.0.34.