The JVM executing the enterprise beas is provided by the container. The container
decides
what classes are allowed to be loaded into the JVM.
The restrictions defined in the EJB spec are to ensure that application are
*portable*, i.e. that
they can be run in *all* EJB containers. If an enterprise bean used functionality
outside of
the portable set (i.e. within the restrictions), it most likely wouldn't run in most
containers.
This
is because the functions that are prohibited by the EJB spec are not implementable in
a uniform
way across all EJB containers.
Vlada
----- Original Message -----
From: Alain Rogister <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 20, 1999 6:48 AM
Subject: Re: Clarification needed on Thread and non-final staticrestrictionsfor EJB
> Vlada,
>
> Vlada Matena wrote:
> >
> > The restrictions apply to the classes that are delivered as part of the
> > enterprise bean code (i.e. to the classes in the ejb-jar file).
> >
> > The restrictions do not apply to the container implementation classes.
> > The JDK classes are considered to be part of the container.
>
> I've been reading this list from the beginning, but I have yet to fully
> understand the restrictions imposed on JNI, threads, use of the I/O API
> etc. The spec does not provide clear rationales for the restrictions (I
> mean something more substantial than "this might create a security
> hole") and does not discuss alternative strategies. As a result, the
> same questions come back again and again on the list, with less than
> satisfying answers like "use CORBA" or "wait for the Connectors API".
>
> Let's take JNI as an example. Here is my attempt at a summary:
>
> - loading a native library inside an EJB instance is a no-no, and the
> container should typically intercept any attempt to do so through a
> proper security policy (but a container provider may decide not to do
> that);
> - since loading a native library is "the responsibility of the
> container" (as per the spec), one would expect that the container
> provides the beans with the ability to request the loading of a native
> library: I am not aware of any way to do this;
> - loading a native library in a helper class packaged in the EJB-jar
> file is also a no-no, because you just said so (I'm not sure if it's
> clearly said in the spec);
> - loading a native library from any code that is not packaged in the
> EJB-jar file is therefore OK: this might be an RMI object living in the
> same VM, an object retrieved from a JNDI tree, a JMS Message Consumer, a
> servlet, whatever...
>
> Is this last point really correct ? If it is, how exactly is that more
> secure than loading the library directly in the EJB instance or a helper
> class packaged in the EJB-jar file ? Supposing that the EJB retrieves a
> serializable object from JNDI and this object loads a native library,
> could/should the container restrict the behavior of this object ? What
> about an RMI object that is living in the same VM but is outside of the
> control of the EJB container ? Could you please clarify the rules ?
>
> Thanks,
>
> Alain.
> --
> Alain Rogister
> Ubiquity s.a.
> http://www.ubiquity.be
>
> ===========================================================================
> 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".
>
>
===========================================================================
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".
