the singleton thing won't work in a portable way, since it is in the responsibility of the container implementer to assign classloaders. A very usual way of doing this is assigning a classloader to every deployed unit (with subdeployment classloaders are child to the enclosing deployment classlaoder). JBoss uses a single loader repository as default and can be configured to use a new one for every deployed unit, which is a different approach.
AFAIK the WAR has to have its own classloader. First it has to look into the WARs lib directory for resources. Then it is going up to look the manifests classpath.
Probably you are able to configure JBoss in a manner you wanted to without the verifier complaining using the <loader-repository> tag in your jboss specific deployment descriptor.
It's hard to tell what's standard, and what's vendor specific.
For example, WebLogic appears to create one class loader for the EAR, and all the EJBs in the EAR share that class loader.
Each WAR in the EAR gets a child class loader, to allow for reloading servlets and JSPs.
Again, all the common frameworks (which are, in reality, pluggable modules) should be in the EAR so that they will be distributed properly in the cluster.
I'll be doing more testing tomorrow using WebLogic. We'll see if the Manifest Class-Path trick works there as well.