Can you file a bug, and I'll remove the restriction from the spec.
I would think (but I'm interested in what other EG members think) that
the "current" CL is the ThreadContextCL, though you can load a resource
directly from getClass()...
-marina
Jean-Louis MONTEIRO wrote:
> 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
>