see below,

Sriram Srinivasan wrote:

> I don't buy this argument . There are any number of ways in which
> you can mess up stability and scaleability. Do you prevent beans
> from calling System.exit()?

yes! Bean shouldn't have java.lang.RuntimePermission(for system exit).

> Do you prevent people from creating
> 200000 JDBC statements when one would suffice?

Yes! The container implements the javax.sql.DataSource and thus has controll on
the connection served to the bean. It can limit the number of connections
served to a bean, it can even have control on the number of statements beeing
created from a connection, it can force the closing of that connection if
needed.

> Do you prevent
> people from writing a deadlock using 3rd party products?

Yes! That is what is being intendet by prohibiting threads creation and
synchronization routine. Note that third party packages used by the bean must
respect bean's restrictions and run under the same security policy.

>
> The EJB server doesn't have control.

Wrong! A good implementation can have full control of all what is hapening into
the server. That's where Java differs from other languages (C++) or paradigms
(COM). That's the Java competitive advantage. The good use of the Java security
framework will allow you to keep control on all what is hapenning (or all
actions performed by the bean).

> <Vendor>
>    The weblogic server does not limit you artificially in this respect.
> </vendor>
>
> -Sriram

I know the live isn't easy under ejb spec. restrictions. But I also know that
all ejb-restrictions are well justified. If you get arround ejb-restrictions
into your server, please notify users about resulting risks. Tell them what
will hapen if they run bean that have runtime permissions (like the
System.exit() above).

Regards.
--
Francis Pouatcha

MATHEMA Software GmbH
http://www.mathema.de

===========================================================================
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".

Reply via email to