Hi, we have several applications, which refuse to work with the 7.0.100 release. The crazy thing is: There are no log outputs showing an failure. In catalina.out we only see, that the application has started. Interestingly, static files in the applications can be accessed, i.e. a "it Works" page. When it come to Java files, they will obvioulsy not been executed, although we can see in the logfile, that they have been registered. The applications also do not produce any output - normally they log their start and stuff in a separate logfile, but this will be kept untouched. It is very hard to find the issue, all I can say, the applications work with 7.0.99 like a charm, but not with 7.0.100 best Thomas
Probably the SCI regression that has already been fixed. Are you able to build Tomcat 7.0.x from source to test the latest code?
(In reply to Mark Thomas from comment #1) > Probably the SCI regression that has already been fixed. Are you able to > build Tomcat 7.0.x from source to test the latest code? Unfortunately not (as we have rules for production enviornments to only use final versions) - would this been included in the 7.0.101 then?
How about a test environment? It would be helpful to know if the issue you are seeing has already been fixed or is a new issue.
(In reply to Mark Thomas from comment #3) > How about a test environment? It would be helpful to know if the issue you > are seeing has already been fixed or is a new issue. Yes, you're right - can you give me hint, where to find it?
I uploaded a build here: http://people.apache.org/~markt/dev/v7.0.101-dev/ This isn't an official release. It is just for testing purposes.
(In reply to Mark Thomas from comment #5) > I uploaded a build here: > http://people.apache.org/~markt/dev/v7.0.101-dev/ > > This isn't an official release. It is just for testing purposes. This seems to work - so I guess you fixed it. Do you have a clue, if this would be released quickly (I guess I'm not the only one, which have this issue)
Thanks for confirming the fix. The monthly release cycle is close to starting so a 7.0.101 release should not be too far away.
*** Bug 64205 has been marked as a duplicate of this bug. ***
*** Bug 64220 has been marked as a duplicate of this bug. ***
I have the same issue as described in Bug 64220 using Tomcat 7.0.102 from https://repository.apache.org/content/repositories/orgapachetomcat-1259/ with the tomcat7-maven-plugin. In WebappServiceLoader line 111 the call to findResources does not return any results. The value of the configFile variable is "META-INF/services/javax.servlet.ServletContainerInitializer". If I re-execute the findResources call in the debugger with removing the preceding "/" in line 111, I get a result: resources = ((URLClassLoader) loader).findResources(configFile) Then my Spring Boot application starts again.
I suspect that is because the class loader being used hasn't got the same work-around that Tomcat's class loader has. I want to run a few tests first but I think the answer is going to be removing the leading slash in that call.
Thanks for the report. Fixed in 7.0.x for 7.0.103 onwards.
Thanks for the quick fix, but I investigated a bit more. There is still something wrong. The application *IS* using WebappClassLoaderBase from Tomcat. I see that there is code to remove the leading slash in line 1574, which is executed. The bug is in line 1594. The call to "super.findResources" still uses the "name" variable, but it should use the "jarPath" variable.
I'm confused. How did removing the leading "/" manage to fix it for you as per comment #10 if, with that fix applied, it is still broken?
Sorry for the confusion. I found this by "visual inspection". You wrote "the class loader being used hasn't got the same work-around that Tomcat's class loader has". Is WebappClassLoaderBase the Tomcat class loader? Because WebappClassLoaderBase is used in my case. And WebappClassLoaderBase line 1594 makes the difference for me. I am just unsure if the "/" has to be fixed in the caller or in WebappClassLoaderBase itself.
No, the web application class loader isn't loading the SCI. It is delegating that to its parent. The fix (in WebappServiceLoader) is the correct one.
Okay, then sorry again. I saw that the "/" removal for jarPath happened in WebappClassLoaderBase and I was afraid that it needs to be done for the call in line 1594 too for satisfying other callers than WebappServiceLoader.
May I ask the question, when the next release will happen? I mean, it's kind of urgent to install an update due to the security breach ...
The new release has been voted last week, but it has been canceled due to a problem. 7.0.103 has been just cut and a new vote will start in few minutes. Check the dev@ mailing list for details.
(In reply to Thomas from comment #18) > May I ask the question, when the next release will happen? I mean, it's kind > of urgent to install an update due to the security breach ... No, it isn't. I assume you are referring to CVE-2020-1938. That can be mitigated entirely with appropriate configuration. Further assistance is available on the Apache Tomcat users mailing list if required.