> In order to get the restriction up and working, you have to define a
> different code base for your beans, which few vendors actually do. That
> would be specified in your java.policy file, not in the EJB server
> itself (there's no API for the container to do that).
>
> Funny, but EJB actually has to go the extra step to place these
> restrictions, and I don't think anybody actually took the time (or ever
> will) to do that.
This is incorrect. It is trivial to add these restrictions, and it
doesn't require a change in a policy file. Here's code to do it:
public class EJBClassLoader
extends URLClassLoader
{
Permissions perms;
public EJBClassLoader(URL[] urls, ClassLoader parent)
{
super(urls, parent);
perms = new Permissions();
perms.add(new java.util.PropertyPermission("*","read"));
perms.add(new java.lang.RuntimePermission("queuePrintJob"));
perms.add(new java.net.SocketPermission("*","connect"));
}
protected PermissionCollection getPermissions(CodeSource source)
{
if (secure)
return perms;
else
return super.getPermissions(source);
}
}
--
Now, all you have to do is load the beans with this classloader, and
you're set.
<vendor>
The EJBoss server, www.ejboss.org, uses this classloader (almost, I've
removed some additional features above for brevity).
</vendor
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.dreambean.com
Question reality
===========================================================================
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".
