Hi. In EJB3.1 spec, section 21.2.2 (Programming restrictions) stands:
The enterprise bean must not attempt to create a class loader; obtain the current class loader;
set the context class loader; set security manager; create a new security manager; stop the
JVM; or change the input, output, and error streams.
Ok, so my
EJB can't do it. How about classes that the EJB uses, possibly deep in the hierarchy? Do they also have this restriction? They are technically other classes, but they execute in EJB context (they can for example use the wrapping EJB's
java:comp naming context).
I am asking this question as we are thinking of using groovy for ad-hoc scripting (formatting output, defining a configuration DSL for some parts and the like), and the way it works is via a custom GroovyClassLoader. If I can't create my own class loader, I can't use groovy either, which would be bad.
As a side note - do you EJB gurus comply with the restrictions? I mean, no filesystem, no class loader, no threading... Some of them make sense, some others seem overly restrictive. For example, we have a WAR that packages JPA and EJBs in WEB-INF/lib (separate jars). The
servlet container can use the filesystem, there is even a special method somewhere (ServletContext?) to get the real path to a resource, but as soon as the border Servlet / EJB is crossed, I can't access files any more, even though it is the same JVM (in our case).
szczyp