Since System.setSecurityManager can be used to change security level at
runtime, the only way to guarantee the correct level is used by the helper
methods is to test if (getSecurityManager != null). This is also the
practice adopt by the JDK runtime.
I have changed per your suggestion but use if (System.getSecurityManager !=
null) instead.
Thanks.
Albert Lee
On 6/3/07, Craig Russell (JIRA) <[EMAIL PROTECTED]> wrote:
[
https://issues.apache.org/jira/browse/OPENJPA-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501065]
Craig Russell commented on OPENJPA-244:
---------------------------------------
If you choose not to have an interface and two classes selected by whether
the security manager is active or not, I'd suggest adding a
static final boolean isSecure = System.getSecurityManager() != null;
and then testing it for each method, e.g.
public static final ClassLoader getClassLoader (final Class clazz)
{
if(isSecure) {
return (ClassLoader) AccessController
.doPrivileged(new PrivilegedAction()
{
public Object run ()
{
return clazz.getClassLoader();
}
});
} else {
return clazz.getClassLoader();
}
}
If the variable isSecure is static final we need to be sure that the class
is never loaded before the security manager is activated, otherwise we will
get the wrong answer.
As the patch is written as of June 3, each call will at minimum create a
new object on the heap that needs to be garbage collected, and calling
doPriv when there is no security manager is a waste.
In any case, it's good to isolate the calls to this class so I'm +1 on
making the rest of the changes and we can worry about the implementation
details when we see if there is any performance impact one way or the other.
> Java 2 Security enablement
> --------------------------
>
> Key: OPENJPA-244
> URL: https://issues.apache.org/jira/browse/OPENJPA-244
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 0.9.8
> Reporter: Kevin Sutter
> Attachments: J2DoPrivHelper.java
>
>
> Via some testing with the WebSphere Application Server, it's been
discovered that we're missing some doPriv blocks through out the OpenJPA
code base. This JIRA report will be used to resolve these issues. More
specific examples will be posted later.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
