But above the JDK in the API means letting the ClassLoader implement something like the java.lang.instrument.Instrumentation interface
By having the standard classloaders used by the server in normal mode as default, and then suclassing them with an implementation of the interface, it could be a configuration option if an application should instantiate with the subclass
The filtering and the potentially "slow" syncronous call to java.lang.instrument.ClassFileTransformer (ClassPool) would only be active if the subclass is used
In this way the AOP would only be able to modify classes in their own context and the ClassLoader hierarky would be intact
The only reson, it could be: fine grained security.
In Apache server you can specify which url are forwarder to Tomcat, and which are not.
If you make Tomcat publicly available all yours applications are accessible for everyone and you must configure all of them to use some security domains (JAAS,etc), by default they aren't configured.
Can you imagine what would happend if somebody will have access to jmx-console?
I takes a minute to shutdown JBoss remotly.