You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@tiles.apache.org by "Antonio Petrelli (JIRA)" <ji...@apache.org> on 2008/10/27 08:34:38 UTC

[jira] Commented: (TILES-324) Cannot call ClassUtil.setContextClassLoader() with SecurityManager

    [ https://issues.apache.org/struts/browse/TILES-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44870#action_44870 ] 

Antonio Petrelli commented on TILES-324:
----------------------------------------

Wow, this is a nasty bug, thanks for pointing at it.
In fact you're right, there is no necessity for the call of setContextClassLoader.
The logic would have been: get the thread's context classloader or, if it is null, get the classloader of the ClassUtil class itself.

> Cannot call ClassUtil.setContextClassLoader() with SecurityManager
> ------------------------------------------------------------------
>
>                 Key: TILES-324
>                 URL: https://issues.apache.org/struts/browse/TILES-324
>             Project: Tiles
>          Issue Type: Bug
>          Components: tiles-core
>    Affects Versions: 2.0.6
>            Reporter: Eddy Chan
>
> In org.apache.tiles.util.ClassUtil.instantiate(String, boolean), there are two calls to setContextClassLoader for the currentThread.  This causes an issue with a SecurityManager that does not grant the RuntimePermission.  In my situation, since this class is in the webapp, the second call to setContextClassLoader causes an issue, since it is in the finally clause.  Two workarounds:
> 1) Remove the calls to setContextClassLoader.  (Not sure the necessity here.)
> 2) Flag whether the first call to setContextClassLoader was originally done, and then conditionally call setContextClassLoader if it was done.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.