Following test drives in gfv3-b64, I deployed a load of jar libraries shared by
all our internal applications (mostly webapps/war artifacts) to <domain>/lib/,
restarted the application server just to find the admin_gui not working anymore.
Upon closer inspection, I figured out that this behaviour could be triggered
reproducibly by dumping a xercesImpl.jar to <domain>/lib/.
We have pretty large webapp files, a bunch of third-party dependencies which
come as jar files, and many of them shared by all the webapps. From this point
of view it is sane not to put the jars into <webapp>/WEB-INF/lib/ but rather
place them directly in some "shared-library" folder, eventually accepting
certain restrictions (servlet.jar, ...).
However, such a folder to store shared libs should be treated in a way so that,
no matter which jar files will be stored there, it should never ever be
capable of damaging the application server as a whole as effects of such a
behaviour may be hard to foresee. Would it be possible to completely wreck, or,
worse, compromise (from a security point of view) the application server by
storing a prepared .jar in <domain>/lib/? At least talking about wrecking the
admin_gui, the answer seems yes.
Proposed solution / enhancement request:
Introduce a "safe shared library" folder which is the place to deploy jar
libraries used by applications (war, ejb, connectors, ...) deployed to the app
server without affecting the behaviour of the app server itself.