> Somebody on this list said that you're not allowed to start threads inside
a
> servlet container. Is this really in the spec (this was claimed), or is it
> implementation-dependent?
I am not sure for the web container. But the situation is even fuzzy for an
EJB container. I believe that in Orion, there isn't much difference between
the two (except for the RMI and wrapper subclasses).
Here is what the Borland BAS4.5 spec says about the EJB programming
restrictions:
--->8---
Verifies in accordance with pedantic EJB 1.1 rules. There are four warnings
that have been classified as pedantic:
-- Throwing java.rmi.RemoteException from a bean method is deprecated.
-- Static fields in the bean class must be final. (This is actually a useful
rule, which is violated by the Java compiler.)
-- The primary key type must define the equals(Object) method.
-- The primary key type must define the hashCode() method.
The behavior of the verifier is that, by default, these rules are ignored.
Choosing the Pedantic option causes violations of these rules to issue
warnings. For deployment purposes, warnings are ignored, meaning that you
can go ahead and deploy beans which have warnings. However, you cannot
deploy beans which have errors.
Keep in mind the following about pedantic verification:
1) Not actually required by our runtime, meaning that your code will work as
is.
2) Questionable altogether, and may well be eliminated from the EJB
specification when people realize how annoying they are.
3) Violated in almost every EJB program ever written, both in our product
and in all the various books ever written about EJB.
--->8---
>>>>>>>>>>>>>>>>>>>>>>>>>>> Especially, note point 3) :-))
-----
Below is a list of programming restrictions defined in the EJB 1.1
specification.
An enterprise bean is not allowed to manage threads and thread groups. It
should not start new threads or resume suspended threads, nor should it
terminate or suspend the running thread. In addition, an enterprise bean
should not change a thread's priority or its name.
An enterprise bean is not allowed to use read/write static fields. Using
read-only static fields is allowed. Therefore, all static fields must be
declared as final.
An enterprise bean is not allowed to use thread synchronization primitives
to synchronize the execution of multiple instances.
An enterprise bean must not use the Java AWT functionality to output
information to a display or to accept information from a keyboard.
An enterprise bean should not use the java.io package to access files and
directories in the file system.
An enterprise bean should refrain from using sockets; in particularly, the
bean should not listen on a socket, accept connections on a socket, or use a
socket for multicast. In addition, it should not set the socket factory used
by ServerSocket, Socket, or the stream handler factory used by URL.
An enterprise bean must not access classes or packages, or attempt to obtain
information about classes, in a manner normally disallowed by the Java
programming language or if the classes are normally unavailable to the
enterprise bean.
An enterprise bean must not access the runtime environment functions
normally handled by the container--create a class loader or access or change
its context, set or create a security manager, stop the JVM, change input,
output, or error streams.
An enterprise bean must not obtain security policy information for a
particular code source as this would compromise security.
An enterprise bean must not load a native library.
An enterprise bean must not define a class in a package, as this is a
function reserved for the container for security reasons.
An enterprise bean must not use the subclass and object substitution
features of the Java Serialization Protocol.
An enterprise bean should be careful if passing this as an argument or
method result. It is safer for the bean to pass the result of
SessionContext.getEJBObject() or EntityContext.getEJBObject().
An enterprise bean is not allowed to access or modify security configuration
objects. For example, it is not allowed to change its
java.security.Identity. Any such attempt will result in the
java.security.SecurityException being thrown.
