Hey
Paul Hodgetts wrote:
> I think I'm losing something in the context of this discussion.
That happens with eternal threads sometimes :-)
> 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 find this hard to understand,
> since the security and transactional context is dynamically set
> based on the particular client access that's occurring. Please
> explain.
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).
See:
http://java.sun.com/products/jdk/1.2/docs/guide/security/permissions.html
and:
http://developer.java.sun.com/developer/earlyAccess/jaas/index.html
(requires JDC membership)
> I'm not having much success locating messages where you describe
> how class loading relates to the restrictions. Would it be
> possible for you to post a brief summary, or to point me to some
> particular messages, or date ranges, or something?
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? ;-)
BTW, although this discussion is mildly frustrating I think it is very
good and productive because these issues needs to be sorted out.
Oh, and we need a EJB-INTEREST FAQ soon to put all these good
discussions into.
/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".
