> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard Oberg
> To me there are two main reasons where the restrictions are useful:
> 1) If it's an EJB it is portable. Period. No "well, if it does
> this or that
> it needs.." crap. By refactoring everything that would be potentially
> dangerous to external libraries we have the simple rule that EJB's
> themselves are always portable.
You lost me here, Rickard. If I refactor I/O to the system
library and have an EJB that depends on this library, how
does that make the EJB more portable ? To use it on a server X,
I have to install this "unsecure" library as well as the EJB
in question otherwise it won't work. In fact, if the library
is referenced statically (i.e. EJB instantiates and uses
library classes directly) the EJB won't even deploy unless
the library is on a CLASSPATH of a server.
So, where's the gain ?
Regs, Bartek
===========================================================================
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".
