tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 60798] New: Nested Jar entry could not be read twice consecutively
Date Wed, 01 Mar 2017 22:38:03 GMT

            Bug ID: 60798
           Summary: Nested Jar entry could not be read twice consecutively
           Product: Tomcat 8
           Version: 8.5.11
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: regression
          Priority: P2
         Component: Jasper
  Target Milestone: ----

We are using fat war packaging for one of our webapps. There are JSP tags
(/META-INF/tags/**/*.tag), inside required jars (/WEB-INF/lib/*.jar).

During JSP compilation, when calling a jar entry (a tag inside a nested jar)
this entry is called twice, with same name, but the InputStream is not at same

# Explanation

1. JSP compilation of a JSP: This JSP references tld (in lib-tld.jar), and this
tld uses a tag (standard syntax) :


2. The tag is loaded one first time, to determine syntax and encoding

It calls:

org.apache.jasper.compiler.JspUtil#getInputStream ->

3. The tag is loaded a second time to parse content, but the return value is an
InputStream at a different position (called by ParseController#doParse)

4. Tag is not properly parsed (no attributes) and JSP does not compile.

# Cause


>    private void gotoEntry(String name) throws IOException {
>        if (entry != null && name.equals(entry.getName())) {
>            return;
>        }
>        reset();
>        JarEntry jarEntry = jarInputStream.getNextJarEntry();
>        while (jarEntry != null) {
>            if (name.equals(jarEntry.getName())) {
>                entry = jarEntry;
>                break;
>            }
>            jarEntry = jarInputStream.getNextJarEntry();
>        }
>    }

When calling the same entry twice consecutively, entry is not null and
parameter name is same as entry.getName(), it loads the same attribute

I've patched the class AbstractInputStreamJar and removed the first three lines
of gotoEntry (reset unconditionnally), and it solved this problem.

# Workaround

It's not reproducible if the war is unpacked (no problem with JarFileUrlJar)
For information, this behavior does not seem to be reproducible with this


You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message