First I should let on that our enterprise application is quite large in size, has been selling for around a decade, and new versions are still being sold (including upgrades to existing versions). As such it predates the existence of servlets, EJBs, etc. Also any repackaging task would be quite enormous. We've considered it certainly, but small tweaks to loaders are [i]much[/i] more cost effective.
The issue here boils down to classes and other resources that are shared by multiple tiers, client, web app, and [custom, pre-EJB] app server. There are many resources that are used by all these tiers.
Further applets load classes from the docroot except where they're available in client jars -- which in turn were really an optimized pre-packaging of classes from the docroot initially. For us this is still largely the case with the exception of 3rd-party jars used by the client, i.e. classes and other resources that might be used by a client reside relative to the docroot and then are gathered into client jars by tooling based on runtime usage testing. Client jars are not guaranteed to be complete and requests for other applet resources fail over to docroot.
Given the client applet situation we started down a path of docroot being the first entry in our classpath even before servlets existed. When servlets came around it always struck me as wrong that there was no standard location in the web app where the client tier and server tier could share the same resources -- but at any rate we altered servlet engine loaders or [less preferably] overall classpaths (thus destroying all web app isolation) to address the situation and continued sharing resources between the client and server tier.
[Message sent by forum member 'jess_holle' (jess_holle)]
http://forums.java.net/jive/thread.jspa?messageID=241977