Hello everyone, My name is Raymond Auge and this is my first message to the list. Hopefully I follow protocol correctly. Let me know if I don't.
---- org.apache.jasper.Constants.IS_SECURITY_ENABLED is a global (static final) constant. As such it is evaluated exactly once. Since Jasper is typically provided as part of the app server this means it's impossible for some later module to enable Java security dynamically. The Java security API is clearly dynamic. It allows for the creation of both security managers and policies created and registered at runtime. The JVM itself always performs dynamic evaluation of security (normally the very same null check which is stored by IS_SECURITY_ENABLED. Scenario demonstrating a problem: 1) start tomcat normally (no security) 2) assuming any normal app is initialized, a JspRuntimeContext will be created and at first invocation Constants.IS_SECURITY_ENABLED = (System.getSecurityManager() != null); is evaluated. 3) deploy some later component (ie. a webapp) which does: System.setSecurityManager(new SecurityManager()); 4) from that point, all Jasper code will provide the incorrect state, app server wide I realize this is a very long standing mechanism. I'm wondering what would be the odds of accepting a patch which enables a dynamic check as opposed to global constant. A further change would be required to initialize security dynamically which I think could be done simply enough without incurring significant performance issue. BTW, this issue affects every app server which uses Jasper (including users of the JSR RI in the Glassfish project) Any thoughts? Sincerely, -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
