Rickard �berg wrote:
>> Since you're still banging your head at this (for some reason), I'll try
> to be more explicit
> below. ;-)
Bingo; exactly what I was looking for.
> Yes and no. If these additional classes are loaded by the EJB
> classloader they are considered
> part of the component and must obey the same rules as EJB's.
OK.
> If they are
> loaded by any other
> classloader they are free to do whatever they want, as long as they obey
> the standard rules of
> the security API framework (i.e. use doPrivileged blocks appropriately).
(Which I'm still having trouble grokking; my homework.)
> As above: if Frobnicator is loaded as a part of the component -> no
> threads may be created. If it
> is not created as part of the component -> any number of threads may be
> created.
Good. Thanks for the explicit answer. So this rules out an
interface-driver approach, kinda: that is, if I want the guts of my
stateless session bean to actually be implemented by a "driver" that
conforms to that session bean's interfaces, and if the driver is
supplied by a third party, then I must call the tech. support department
of the vendor of that product and determine from them whether or not
their product uses threads or file I/O (or, I suppose, I could load
their product up and see if the SecurityManager barfs... :-)).
Consider something like this:
public class KitchenSinkBean extends SessionBean {
// bunch of methods with code in them
private FooDriver driver;
public void doSomethingComplicated() {
// if driver not loaded, load it here:
if (this.driver == null) {
// load driver
}
driver.doSomethingComplicated();
}
}
public interface FooDriver {
public void doSomethingComplicated();
}
public class ComplicatedDriver implements FooDriver {
public void doSomethingComplicated() {
// go do nasty stuff with threads, I/O, etc.
}
}
...and assume that an instance of ComplicatedDriver is loaded. I'd like
to have bits of my session or entity beans pluggable so that my project
can take advantage of competing third-party products that provide some
of this functionality already. It looks like if any of these products
use threads I have to ensure that they're loaded by a different
classloader and available (via JNDI, I guess?) to my beans instead of
simply creating new instances of them and loading them up via the
context class loader. Or, more briefly:
Implementations of interfaces that could be provided by unknown
vendors must be loaded by a non-EJB classloader.
> Does this answer your query? If it does not I suggest that you:
> 1) Check the archives
> 2) Read up on the Security API framework (java.sun.com/security I think)
#2 is definitely on the list (again).
Cheers,
Laird
===========================================================================
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".
