Paul, consider the following part of the servlet spec:
>>>> SRV.9.7.1 Dependencies On Extensions When a number of applications make use of the same code or resources, they will typically be installed as library files in the container. These files are often common or standard APIs that can be used without portability being sacrificed. <<<< So shared library classes can be made available in a higher classloader. Furthermore: >>>> SRV.9.7.2 Web Application Classloader The classloader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal J2SE semantics using getResource. It must not allow the WAR to override J2SE or Java servlet API classes. It is further recommended that the loader not allow servlets in the WAR access to the web container's implementation classes. It is recommended also that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs. <<<< Note the use of "recommended". Bottom line for you: The obvious solution is completely within-spec. /LS -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
