Clarification needed on Java EE spec

Is it against the Java EE spec to create new classloader from within the code flow of any application?

I 开发者_StackOverflow社区want to load classes at runtime into a separate class loader that will be created from the application.

It is definitely a violation of the spec. See here for example:

Attempting to create or obtain a class loader, set or create a new security manager, stop the JVM, change the input, output, and error streams. That restriction enforces security and maintains the EJB container's ability to manage the runtime environment.

There are two ways to respond to your underlying need. One is that if you envision deploying internally on a specific appserver, it doesn't matter - as long as you know that it works. You are most likely to mess up hot deployment, so that is where you should test.

The other is to see what Java EE or your specific app server give you. Weblogic, for example, allows you to configure the class loading hierarchy of your ear. At this point Java EE is mature enough that if you have a legitimate need, you can almost certainly get it done. It may not be nice, pretty, comfortable or as easy as doing your custom class loader, and may be app server dependent but it would likely be able to be made to work.

I am not 100% sure if it applies to all parts of a Java EE application (e.g. web apps), but from EJBs, your are not allowed to create new class loaders:

From the JSR 220 (EJB 3.0, Core Contracts and Requirements):

"21.1.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."