On 04/01/2021 11:54, Romain Manni-Bucau wrote: <snip/>
> Well it also depends the classpath. I fully agree with a plain tomcat not > customized you don't get much - just have a more consistent usage of > resources but it is about being purist so not that interesting to me here. > Now make your classpath bloated - yes some people do ;) but I guess having > ~100jars is not that rare too these days - and this is really slower, in > particular with a custom security manager getResource check even if it got > optimized. If an app is that bloated then I'd be surprised if the changes proposed had any noticeable effect. > Another interesting case is the tomee one or more exactly: the embedded > one. Let's assume somebody uses tomcat embeded (not rare these days) and > its dependency resolution comes with a servlet-api which is not tomcat one > (not rare too), then it can miss the resources because it is a pure API or > the project it comes from grab them from elsewhere. Why would he get > warnings if he does not use the validation. Any valid API JAR needs to include the resources as passing the TCK requires validation to be enabled - and that requires the schemas to be available. The current consensus of the Jakarta Servlet team is that the Servlet API JAR must include all the schema required for validation. Error messages where the root cause is an invalid API JAR are not something that concerns me. (As an aside, due to the dependencies between the schema it means that the Servlet API JAR has to include all the schema for the JSP API as well - they can't be decoupled into the JSP API JAR). > So to summarize I see two benefits to update a bit the impl: > > 1. Makes it smoother for embedded case (where validation is rare) > 2. Makes is a bit faster for highly customized standalone instances > (enterprise prebundled server/layer) > > Indeed I don't expect - can be done technically but hope it is never true - > both to be true at the same time :s. 1 assumes an invalid API JAR so I don't consider that to be a valid use case. 2 looks to be the most likely (only?) use case where there is potential benefit to performing this optimisation >> The Maps are public but they aren't part of what we consider to be >> Tomcat's public API so while this would technically be an API change, I >> don't think that is a reason not to do this (or limit it to 10.1.x) > > Not sure I got this, it is just about chaging the internals of the map so > API does not break (like overriding get to be lazy but not changing the > generics). Ah. I was thinking of a simpler implementation that switched the Map<String,String> to Map<String,Supplier<String>) or whatever results in the simplest code. That brings us back to the complexity vs performance benefit question. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
