Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
From: costin@eng.sun.com
Sender: costin@costin.dnt.ro
Message-ID: <39B56D7E.CF8F2528@eng.sun.com>
Date: Tue, 05 Sep 2000 15:02:39 -0700
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: [PATCH] loading jar files from lib directory under SCCS
References: <10F82FC788E0D311AB820060083EAE1E08183C@mail.netbeans.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Petr,

The spec is clear, all files ending with jar under WEB-INF/lib should
be included. On the other side, this refers to the "war" format, not
the runtime format.

One option is to check if the jar files are valid before including
them - that's perfectly fine and I can't see any reason for no doing that.

An alternative ( that should work for all special features that someone
needs ) is to implement this feature in a separate Interceptor, and include
it instead of LoaderInterceptor ( you can make changes to LoaderInterceptor
if it helps - like add a checkFile() that you can override with your special
code, or use an interface like FileFilter, with a default that doesn't filter
anything and a way to include an alternate implementation).

I think it would be a good idea to create a jakarta-tomcat/src/extra ( or
contrib ) and keep all "special" modules -  non-spec features, integration
with various systems, etc.

You can also alter this patch to provide this filtering as a config option -
with the default beeing "filter nothing".


Costin


> The problem is that TeamWare creates a "SCCS" subdirectory under each
> directory, and in this directory it creates files with similar names as the
> original directory. So for example if the WEB-INF/lib directory contains a
> file called library.jar, then WEB-INF/lib/SCCS directory will contain a file
> called s.library.jar. This file is not a valid jar file. So when Tomcat adds
> all jars from WEB-INF/lib and its subdirectories into its classpath, the
> classloader will complain about a corrupted jar file and thow an exception.
>
> This can be fixed by not including SCCS in the directories from which jar
> files are recursively added into the web app classpath.
>
> The following patch is against the tomcat_32 branch, the patch for Tomcat
> 3.3 would be analogous.
>
> How do you feel about this patch ? And what about for tomcat_32 ? Also, do
> you know any other version control systems which could have the same problem
> ?
>
> Petr
>
> cvs server: Diffing .
> Index: LoaderInterceptor.java
> ===================================================================
> RCS file:
> /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/context/Attic/LoaderInt
> erceptor.java,v
> retrieving revision 1.2.2.1
> diff -u -r1.2.2.1 LoaderInterceptor.java
> --- LoaderInterceptor.java      2000/07/29 18:20:52     1.2.2.1
> +++ LoaderInterceptor.java      2000/09/05 16:56:37
> @@ -131,6 +131,8 @@
>          FilenameFilter dirfilter = new FilenameFilter() {
>                 public boolean accept(File dir, String fname) {
>                     File f1 = new File(dir, fname);
> +                    if ("sccs".equals(fname.toLowerCase()))
> +                        return false;
>                     if(f1.isDirectory())
>                         return true;
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org