DO NOT REPLY [Bug 19319] New: - Always copy Jar-files during setup

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19319>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19319

Always copy Jar-files during setup

           Summary: Always copy Jar-files during setup
           Product: Tomcat 4
           Version: 4.1.24
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: michael.eriksson@bauer-partner.de


Note: Depending on point of view this might alternatively be filed as
bug instead of enhancement. I choose enhancement since the bug is provoked by
very special circumstances.

The attached patch extends o.a.c.loader.WebappLoader to always copy jar
files when a corresponding configuration attribute is set.
(Currently the jars are copied when WEB-INF/lib is in a War-file, not when it
is an actual filesystem directory.)
This allows for a DirContext that reads Jar-files from several locations.

Background:
To faciliate the development process I had the requirement that tomcat must be
able to read files (e.g JSPs) from several differen parallel directory
structures. This was easiest to solve by extending FileDirContext in a
proprietory maner. Tests showed errors from WebappLoader during repository
setup. (Other parts of tomcat seem to be working fine with the extension.)

E.g. 
java.util.zip.ZipException: The system cannot find the file specified
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(ZipFile.java:112)
        at java.util.jar.JarFile.<init>(JarFile.java:117)
        at java.util.jar.JarFile.<init>(JarFile.java:82)
        at org.apache.catalina.loader.WebappLoader.setRepositories
(WebappLoader.java:1095)
        at org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:688)
        at org.apache.catalina.core.StandardContext.start
(StandardContext.java:3530)
        at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
        at org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
        at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
        at org.apache.catalina.core.StandardEngine.start
(StandardEngine.java:347)
        at org.apache.catalina.core.StandardService.start
(StandardService.java:497)
        at org.apache.catalina.core.StandardServer.start
(StandardServer.java:2190)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:512)
        at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
        at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)

This occurs when one of the extra WEB-INF/libs contains a Jar-file not present
in the "real" one, because WebappLoader gets the names of the Jar-files from
the current DirContext, but the actual JarFile-instances through a hardcoded
call.  By activating the copy-mechanism, which copies _all_ Jar-Files to one
location in DirContext based maner, this problem is eliminated.

As an alternative one could possibly change the code to get the
JarFile-instances in a more flexible way.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org