https://bz.apache.org/bugzilla/show_bug.cgi?id=57823
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
An empty class path element is treated by the JVM as the current working
directory.
The class path is normally only scanned when the JarScanner is explicitly
configured with scanBootstrapClassPath="true".
I suspect that starting via the init.d script sets the current working
directory to '/' which is why the change in behavior is observed.
I'm against adding code to skip "file:/" in the JarScanner since that is the
start of a slippery slope where we get all sorts of suggestions for what should
be skipped. In essence, this is a configuration error and needs to be fixed at
source - where the class path is set. Tomcat has code that optionally adds a
separator when appending entries to the class path depending on if it is
currently set or not. This init.d script should have the same logic.
I looked at adding some sort of warning if scanning a class path location was
too long but I'm not convinced that this problem affects enough users to
justify adding the code (this is the first report I can recall in my 10+ years
working on Tomcat). The general "take 3 thread dumps 10s apart and compare"
advice appears (to me) to be good enough to handle this case.
Given the above, I'm resolving this as WONTFIX.
--
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
