https://bz.apache.org/bugzilla/show_bug.cgi?id=66370
--- Comment #6 from Mark Thomas <ma...@apache.org> --- Looking at comment 0, this line appears in the stack trace: org.apache.jasper.runtime.JspFactoryImpl.getJspApplicationContext(JspFactoryImpl.java:265) I can't match that to any current or historical Tomcat version. It also appears to be missing a privileged block (which Tomcat versions all have) which would avoid the problem. Are you using a modified JspFactoryImpl? If so, this is an issue that needs to be addressed in that modified JspFactoryImpl. Looking at comment 4, I'd like to see the full stack trace to see what is calling jakarta.el.Util since that is a package private class. Looking at the history here: Bug 62080 Some non-Tomcat users of the EL API Jar provided by Tomcat stated a need for additional privileged blocks. While they are known not to be required by Tomcat, they were added. Bug 66294 Tomcat users report that the additional privilege blocks causes performance issues. The solution was to make the use of the additional privilege blocks optional. This was controlled by a system property. The complication is that this also must be called from within a privileged block. Again, this is not an issue for Tomcat. This bug At least one non-Tomcat user of the EL API JAR doesn't use privileged blocks where Tomcat does. Things are not helped by the limited information provided in bug 62080 that started all of this. At this point I see three possible ways forward: 1. Users of the Tomcat provided EL (Open Liberty and others) use privilege blocks for the same calls Tomcat uses them for. 2. The changes for bug 66294 and bug 62080 are reverted. 3. Users stop using the SecurityManager as it is going to go away eventually and this is an opportunity to find an alternative solution to whatever problem using a security manager is currently solving for them. Option 3 seems highly unlikely. Some variation of option 1 might well turn out to the fix for the problem described in bug 62080 but given the lack of information in that bug it is hard to tell. I'm currently leaning towards 2 and if bug 62080 is re-opened, we can dig into exactly why it is happening. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
