https://bz.apache.org/bugzilla/show_bug.cgi?id=60798
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
Assignee: dev@tomcat.apache.org
Reporter: charles-edouard.pois...@kosmos.fr
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
position.
# Explanation
1. JSP compilation of a JSP: This JSP references tld (in lib-tld.jar), and this
tld uses a tag (standard syntax) :
Ex:
<tag-file>
<name>autocomplete</name>
<path>/META-INF/tags/autocomplete/autocomplete.tag</path>
</tag-file>
2. The tag is loaded one first time, to determine syntax and encoding
(org.apache.jasper.compiler.ParserController#determineSyntaxAndEncoding).
It calls:
org.apache.jasper.compiler.JspUtil#getInputStream ->
jar.getInputStream(jarEntryName);
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
org.apache.tomcat.util.scan.AbstractInputStreamJar
> 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
jarInputStream
(org.apache.tomcat.util.scan.AbstractInputStreamJar#getInputStream)
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
revision:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/scan/JarFileUrlNestedJar.java?view=markup&pathrev=1742245#l76
Regards,
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
