On 4/5/2020 2:20 AM, Mark Thomas wrote:
On 05/04/2020 05:10, Jerry Malcolm wrote:
<snip/>
This is on a 8.5.x. I did a yum update. So I assume it's close to the
latest point release of 8.5. Maybe I'll have a clearer mind tomorrow
and see something obvious.
Did you look in the changelog?
Hint: search for "jarsToSkip"
Mark
Thanks, Mark.
The change log says to skip scanning if the skip parameter is set to
"*". It doesn't say to ignore jarsToScan if jarsToSkip=*. If the
design is intended to ignore jarsToScan override if jarsToSkip=* it
seems to me that it defeats the whole purpose. Is that the intended new
design to ignore jarsToScan if jarsToSkip=*? (I tried clicking the link
to the defect, but it times out and I can't view it) The change log
also does not explain why it ignores the jar files that are specifically
listed in jarsToSkip if they are listed individually. With the new
design, if I have a 'billion' jar files and want to scan 5 of them, what
is the correct way to define them?
Maybe I'm not understanding the release numbering philosophy. I was
under the impression that a minor (8.5.xx) update was only for cleanup
and bug fixes and should never require code changes on my part to
continue running. I do yum updates by habit often. I may be doing it
wrong, but I have been trusting that a yum update of minor releases of
products are safe with existing client products. I'm really surprised
that a minor point release of 8.5 would include a change that is
intended to start ignoring a parameter that was honored in the previous
point release (jarsToScan). Maybe that was not intended. But from
everything I can tell, that's what is happening. My functioning code
broke when I did the update.
What am I missing?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
