Getting the following exception when running JSTL in the webcontainer runtime with security turned on: java.security.AccessControlException: Access denied (java.lang.RuntimePermission getClassLoader) at java.security.AccessController.checkPermission(AccessController.java:104) at java.lang.SecurityManager.checkPermission(SecurityManager.java:547) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:189) at java.lang.Thread.getContextClassLoader(Thread.java:484) at org.apache.taglibs.standard.tag.common.fmt.BundleSupport.findMatch(Unknown Source) According to http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html, the following restrictions are applied: If the caller's class loader is null, or is the same as or an ancestor of the context class loader for the thread whose context class loader is being requested, no permission is needed. Otherwise, java.lang.RuntimePermission "getClassLoader" is required. In the org.apache.taglibs.standard.tag.common.fmt.BundleSupport.findMatch, among other areas, JSTL is calling Thread.currentThread().getContextClassLoader()); Since JSTL is now a part of the JEE5 runtime and not a jar added to an application, these calls to the classloader need to be wrappered with a doPriv block.
I see three locations that call getContextClassLoader(): src/org/apache/taglibs/standard/tag/common/fmt/BundleSupport.java (twice) src/org/apache/taglibs/standard/tag/common/sql/DataSourceWrapper.java While JSTL is a part of JEE5; we currently don't have any strong plans for a 1.2 compliant release, so effort is on a version of the 1.1 spec with bugfixes. So you should still be adding a jar to the runtime. If the JEE5 one is the only scenario for this bug, then it's probably best reported to the Glassfish implementation. https://glassfish.dev.java.net/
Now fixed.