Hi,
As for Java IO restrictions, I'd like to also discuss Classloading
restrictions.
Extract from EJB 3.1 FR - 21.2.2 Programming Restrictions
[...]
• 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.
These functions are reserved for the EJB container. Allowing the enterprise
bean to use these functions could compromise security and decrease the
container’s ability to properly manage the runtime environment.
[...]
First, that's not clear for me what is the "current" classloader.
Apologize if the question is stupid, but does it mean "thread context class
loader" or "component class loader (ie. this.getClass().getClassLoader())"?
I guess it's relevant to disallow setting the classloader, but why
preventing to obtain the classloader as well as creating classloader?
IMHO, the point is only to avoid changes in container managed classloaders,
then it does not matter if the user actually creates a classloader or wants
to obtain an existing one?
I know that there are other rules preventing reflection API usage, ... but
to load resources for example, it can be useful because the user does not
need to use the Java IO api.
Moreover, if we refer to Java EE 6 spec - EE.6.2.4.7 Context Class Loader,
it's fully acceptable to get the classloader and load resources
(#getResource()) from the jar/ear/war.
Is it relevant to make things more consistent between Java EE Spec and EJB
Spec?
Any thoughts?
Cheers,
Jean-Louis