tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 60963] Optimize class loading for unpackWARs=false case
Date Wed, 19 Apr 2017 20:01:28 GMT

--- Comment #12 from Thomas Meyer <> ---
(In reply to Konstantin Kolinko from comment #11)
> (In reply to Thomas Meyer from comment #8)
> > 
> > Theoretically we want those bytes to be counted, but the ZipInputStream
> > doesn't read anything in it's construction phase, that's why the whole "fast
> > forward skipping works at all".
> > And yes this is a somewhat hackish solution but it works.
> > 
> 1. I do not know whether this is a concern (I have not looked at the patch),
> but note the behaviour that was recently reported as bug 60940:
> JarInputStream constructor does read MANIFEST.MF and META-INF/ directory
> entry that may precede it.

Yes, I saw this and it's still done after the patch.

What I didn't finish to understand is the validation of the signed MANIFEST.MF
entries. Is it really enough to just read through the whole JAR file with a
JarInputStream with getNextJarEntry() and everything is automagically checked
for correctness?

Do we care that a WAR file contains only correct signed JAR files? I never
really was involved in the topic signed war files and/or containing jar files
inside a war file.

> 2. Zip* and Jar* APIs differ in their handling of i18n filenames. JAR
> specification uses UTF-8 for file names, Zip uses platform encoding by
> default.

That is an important hint, I think we should really go for an minimal
functional ZIP "PK entry" parser to extract the offset of each "PK entry
start", to fast forward in the jar file inside the war file.

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