tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [VOTE] Release build 4.1.39
Date Wed, 19 Nov 2008 21:04:20 GMT
sebb wrote:
> However, there are several binary files that are different:
> connectors/jni/native/os/win32/logmessages.bin
> connectors/procrun/bin.../tomcat*.exe
> This suggests a packaging error - perhaps these bin files were
> incorrectly formatted to correct the line-endings?
Looks like. I'll get it fixed in svn in case there is another release.

> Also, the procrun/README.txt file refers to Tomcat 5 (trivial)
A result of sharing connectors between 4 & 5. I'll get that fixed too.

> There are no top-level LICENSE and NOTICE files in the archive;
> instead there are various different files at different levels of the
> directory tree. Not every LICENSE file has an accompanying NOTICE
> file.
A result of pulling together various source trees.

> The binary zip archive has several empty directories that are not in
> the tgz version:
> logs
> shared
> work
> common/classes
> common/classes
> Is this intentional?
No, but they will be created as required.

> The binary archives have one copy each of tomcat4.exe and
> tomcat4w.exe; I presume this is the version for Intel 32 bit. Why not
> include the amd64 and ia64 versions as well?
The packaging pre-dates those versions being available.

> The NOTICE and LICENSE files in the binary archive refer to several
> products that don't seem to be included (at least not as separate
> jars)
> JUnit
> pureTLS
> Tyrex
That is me being over cautious and including all the libs you need to do a
full build on a pre 1.4 JDK.

> ===
> Findbugs reports lots of bugs, but I don't know if they relate to code
> that is actually
> used or not.
> For example, the org.apache.tomcat.util.threads.Reaper class uses a
> boolean field "running" to communicate with a different thread, but
> fails to synchronize access and does not use volatile.

As far as I can tell, not used. There is a lot of code like that that I am
trying to clean up in trunk. It isn't worth the effort to back port it.

If we were seeing bug reports for TC4 then I'd be worried but we aren't.
But those people that are using TC4 seem happy with it - they just need the
security fixes.

I'll fix the obvious errors in case there is another 4.1.x release but I
don't see anything here to stop 4.1.39.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message