Short answer:
This has been asked lots of times before (by you on a number of
occasions). Everything you need
to know about this is in the archives in replies by myself and others.
Long answer:
Since you're still banging your head at this (for some reason), I'll try
to be more explicit
below. ;-)
On Wed, 5 Jul 2000 10:22:48 -0400, Laird Nelson
<[EMAIL PROTECTED]> wrote:
>The specification does not allow EJBs to use synchronization primitives
>or to create threads of their own. This list has also implied that this
>means that an EJB cannot call another piece of code which might create a
>new thread internally.
That is both correct and incorrect depending on which classloader is
used to load these
additional classes.
>Question #1: Is this latter implication indeed true?
Yes and no. If these additional classes are loaded by the EJB
classloader they are considered
part of the component and must obey the same rules as EJB's. If they are
loaded by any other
classloader they are free to do whatever they want, as long as they obey
the standard rules of
the security API framework (i.e. use doPrivileged blocks appropriately).
>Question #2: Consider the following scenario:
>
> // inside bean class
> public void someBusinessMethod() {
> // delegate to third party product that provides this
> // functionality:
> Frobnicator frobnicator = FrobnicatorFactory.getFrobnicator();
> frobnicator.someBusinessMethodImplementation();
> }
>
>What if frobnicator.someBusinessMethodImplementation() (last line above)
>results in a new thread being spawned to perform the work? May this be
>legally blocked by an EJB1.1-compliant container? If so, how will it be
>blocked? Will a SecurityException be thrown?
If the Frobnicator is loaded as a part of the EJB, then it is a part of
the component and must
obey the rules. The rules are checked by a SecurityManager
implementation, so yes,
SecurityExceptions will be thrown.
>Question #3: Using the same scenario, what if
>frobnicator.someBusinessMethodImplementation() performs a lot of work in
>parallel via multiple threads, waits for them all to complete, and then
>returns synchronously? (That is, what if at the termination of the
>method the number of threads running in the VM is equivalent to the
>number of threads running in the VM when the method was called? Does
>this affect any restrictions (I'd guess not)?)
As above: if Frobnicator is loaded as a part of the component -> no
threads may be created. If it
is not created as part of the component -> any number of threads may be
created.
>Question #4: The implication from all this seems to be that I must know
>whether a third party product uses threads internally if I wish to call
>it synchronously from an EJB. If a product does create threads, then it
>seems that I am forbidden from calling it if I wish to be fully EJB 1.1
>compliant. Doesn't this violate OO programming?
This is only correct if the 3rd party product is to be contained as a
part of the component.
If it is not a part of the component - a typical example would be a JDBC
driver or JMS
implementation - then this 3rd party component must be well-written in
the sense that it must use
doPrivileged blocks appropriately. This is good OO-programming by the
JDBC driver provider which
is hiding potentially dangerous operations (such as I/O, or thread
usage) behind a safe API (such
as java.sql).
Does this answer your query? If it does not I suggest that you:
1) Check the archives
2) Read up on the Security API framework (java.sun.com/security I think)
best regards,
Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
===========================================================================
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".
