> > 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).
I think we'll have to agree to disagree on all these points. I tend to
be a heck of a lot more trusting of the programmer. I don't like to be
policed myself, nor do I force it on anyone. There are very practical
transaction processing monitors that are eminently useful and not
paranoid about what a programmer could do: Tuxedo, CICS and Encina.
Sure there are exceptions; allowing an admin to limit the maximum
number of database connections (not statements) and to throttle
incoming connections if the server is loaded, implementing checked
transaction behavior, etc. These are problems that one typically sees
in practice and have been plugged on a case by case basis. My opinion
is that there's no need to get paranoid about what a programmer could
do. It doesn't help anyone and it limits creativity and performance.
99% of programmers are neither malicious nor complete idiots; they may
design something wrong and will learn soon enough not to do it.
-Sriram
===========================================================================
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".
