Hey
Vlada Matena wrote:
> PS: Note that there is no security permission JDK to disallow an enterprise bean to
> start a new thread. Therefore, we currently do not require that an EJB container be
>capable
> of enforcing the rule that an enterprise bean must not start a new thread. We are
>looking
> into a solution that would allow the container to enforce this rule.
>From java.lang.Thread.java (on constructor call, g is threadgroup):
"
/* checkAccess regardless of whether or not threadgroup is
explicitly passed in. */
g.checkAccess();
"
And in java.lang.ThreadGroup.java:
"
public final void checkAccess() {
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkAccess(this);
}
}
"
And finally in SecurityManager:
"
public void checkAccess(ThreadGroup g) {
if (g == null) {
throw new NullPointerException("thread group can't be null");
}
if (g == rootGroup) {
if (threadGroupPermission == null)
threadGroupPermission =
new RuntimePermission("modifyThreadGroup");
checkPermission(threadGroupPermission);
} else {
// just return
}
}
"
So not letting the bean have RuntimePermission("modifyThreadGroup")
seems to do the trick. What have I missed?
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
