You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2003/07/26 01:41:03 UTC
DO NOT REPLY [Bug 21901] New: -
JasperLoader inconsistently tests SecurityManager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21901>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21901
JasperLoader inconsistently tests SecurityManager
Summary: JasperLoader inconsistently tests SecurityManager
Product: Tomcat 4
Version: 4.1.24
Platform: All
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper 2
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: willh@msoft.com
I found this when trying to get Tomcat 4.1.24 running as a client to Weblogic 8.
While running a standard Tomcat distribution with no Security Manager, when the
Weblogic client classes initialize, they appear to check for a Security
Manager, and if it does not find one, it installs one.
When the JasperLoader's contructor initializes, it caches the
System.getSecurityManager() into the local securityManager instance variable.
However, later on, it checks to see if System.getSecurityManager() is not null,
and if true, it then tries to use securityManager. When something like Weblogic
installs its own Security Manager behind the back of the JasperLoader, you get
an ugly NullPointerException because while System.getSecurityManager() is not
null, securityManager IS null.
Now, I do not know the reason why securityManager is cached at all, so whatever
reasoning is behind that determines how to properly fix the test so that the
behavior is consistent. Simple oversight, and a subtle bug.
For my case, I work around it by creating a permiscuous catalina.policy and
starting Tomcat with -security. This seems to prevent Weblogic from loading its
own.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org