Hey
Jon Tirsen wrote:
> The reasons for the restrictions of file-I/O, threading, etc. is not there
> primarily because of security. They are there primarly because of
> resource-management and redundance. Or rather, giving the
> ejb-server-developer the freedom of implementing these features.
I never said that the restrictions are there because of security
concerns. I explained the "what" and the "how", but never the "why". And
while I agree that the above factors are important, they're not the
primary reason. The primary reason is portability.
Why?
Because it must be absolutely without a doubt possible to say that any
bean is portable to any platform/server by way of logical deduction.
This is one of the primary goals of the EJB specification. One way of
doing this is to use the "common denominator" trick (a la AWT), which in
EJB is implemented by having the security restrictions. This causes all
possibly non-portable actions to be put into external libraries. So,
when you need to port an application you don't have to touch the
application (since it is, by definition, already ported), but only the
libraries.
IMHO of course.
> The restriction for accessing static-fields is based upon the fact that
> "thou shalt not make any assumptions on which virtual machine your running".
> The ejb-server can choose to move you from one VM to the other at any time
> (probably not _in_ method-call, but close). Pretty much the same goes for
> using simple file-I/O. One cannot assume what actual server (and thus
> filesystem) you are on right now. You could actually be deactivated and
> reactivated from different host at any time (even, for example, from NT to
> Solaris).
You are calling this "resource-management and redundance" above, but I
think this is only practical details. The main result of your above
description is portability.
In principle I think we mean the same thing, only using different
vocabulary. ;-)
/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".
