Rickard �berg wrote:
> > Are you saying that none of the restrictions (threads, I/O, etc.)
> > have anything to do with the thread originating from the client's
> > invocation of the bean method?
>
> Exactly.
I'm not sure that I buy into this, but I need to go off and read up
before I can express an informed opinion. I still think the thread
context is significant when accessing resources like JDBC, JMS, and
J2EE connectors. The class loader seems significant when accessing
library classes. Perhaps *both* play a part in the restrictions?
> Security in EJB is based on *who does what*. Security in the Java2 SDK
> is based on *who wrote what code*. Big difference. The first is related
> to threads, the second is related to ClassLoaders (and CodeSource's to
> be exact).
Interesting. More to read...
> The restrictions described in the EJB1.1 specification relates to the
> Permissions-based API as defined in Java2, which is CodeSource based,
> which eventually translates into ClassLoader issues, not threads.
>
> Need more? ;-)
Thanks, you've given me references to track down and lots to think
about!
> BTW, although this discussion is mildly frustrating I think it is very
> good and productive because these issues needs to be sorted out.
Absolutely! Someday we'll have a set of best practices and
techniques to use when pushing the EJB envelope. These discussions
are vital in forming those.
Your posts are much appreciated.
Thanks,
Paul
===========================================================================
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".
