Petr Jiricka wrote:
Has it? I saw some commits in the area of jar scanning, but not this one.
That hasn't been committed yet, indeed.
I too agree that limiting the number of jars scanned could substantially improve first start performance, however I am worried that the solution as suggested by Jan will make it too easy for the users to shoot themselves to the foot. Also, unless the user does some manual setup, there will be no performance gain,right? So wouldn't it be better to have a hardcoded list of well-known jar files that should be excluded from scanning? This would include all jars found in the Tomcat installation.As Jan has already pointed out, it should improve the startup time for Tomcat 5 (since scanning TLD files is a major hit).
I also think that under no circumstances the jar files in WEB-INF/lib should be excluded from scanning, as that is in conflict with the spec.
Or is there something I am missing about the proposal?
Yes, there is.
There's a serialization file which is used to avoid rescanning, unless a JAR is modified.
That's true, but that does not help on the very first start, only on subsequent restarts. So I see that this proposal will not represent any performance improvement on second and subsequent starts. I still think we should look for a way to improve the first start time.
I think this is good enough, and hence my -0 (I'm leaning towards -1 now, as this could indeed be misused; I'd like to see some performance improvement before changing my vote).
What I don't like about Jan's proposal is the need for user configuration. But what's wrong with having a list of well known jar files and skipping those?
Petr
Remy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
