Hi Chris, On 20.04.2021 16:59, Christopher Schultz wrote: > On 4/20/21 07:06, Rony G. Flatscher (Apache) wrote: >> On 19.04.2021 17:32, Christopher Schultz wrote: >>> On 4/18/21 08:06, Rony G. Flatscher (Apache) wrote: >>>> On 11.03.2021 12:23, Rony G. Flatscher (Apache) wrote: >>>>> On 11.03.2021 11:53, Mark Thomas wrote: >>>>>> On 10/03/2021 15:14, Rony G. Flatscher (Apache) wrote: >>>>>>> Is there a way to know/infer that a JSP got freshly compiled from e.g. >>>>>>> a taglib library? >>>>>>> >>>>>>> For caching purposes it would be necessary to learn whether a JSP got >>>>>>> recompiled as the cache >>>>>>> should >>>>>>> be purged in that case. >>>>>>> >>>>>>> Is there a way to find out whether a JSP run is the very first after >>>>>>> (re-)compilation? >>>>>>> >>>>>>> Or can one rely that if a JSP gets recompiled that a new PageContext >>>>>>> gets created for it (or if >>>>>>> reused does not contain any custom attributes placed there earlier at >>>>>>> the PAGE_SCOPE)? >>>>>> Page scope gets reset at the end of a request so that won't work. >>>>>> >>>>>> It might not be perfect (containers are allowed to unload unused >>>>>> servlets/JSPs) but in you are >>>>>> using Tomcat and haven't configured maxLoadedJsps or jspIdleTimeout then >>>>>> you should be able >>>>>> to use >>>>>> the jspInit() method. (See JSP spec for details). >>>> >>>> It seems that the implicit JSP "page" object can probably be used to >>>> determine whether a JSP got >>>> recompiled as its hashCode() changes after recompilation. >>> >>> Something safer might be to keep a cache of datestamps keyed by JSP name >>> (or whatever). When the >>> JSP's init() method is called, you could update the datestamp. >>> >>> Or do you need to know about the recompliation before the init() is called? >> >> The BodyTag interface [1,2] does not define an init() method, you think >> probably of the Servlet >> interface [3,4]. > > Aha, it wasn't clear to me that you needed to know at the taglib level that a > JSP had been > recompiled. > >> Ad 'page' implicit object: if the 'page' object gets referenced in the >> taglib, then a re-compiled >> version of the same JSP page is guaranteed to have a different hashCode() >> value > > Really? That seems ... awfully convenient and also quite hacky. Do you have a > reference to the > spec that guarantees that modified hashcode?
Sorry, it is not "guaranteed" (there are no such specs), it should have probably read "guaranteed for all practical usages". (When the caching of inline scripts gets implemented it may use the page's className or the className@hashCode format as a string index into a HashMap and then check whether the object exists and if so, is equal to the current 'page' object and act accordingly.) >> and as such suffices >> to determine whether a page got compiled since the last time this got >> checked in the taglib. The >> motivation for learning about a (re-)fresh(ed) page is to remove any cached >> compiled scripts of that >> jsp (if it got recompiled then something got changed in the jsp, so also >> scripts might have changed) >> and from then on build a new cache. > > Yeah, I don't see a great way to do that. You can get the ServletContext from > the PageContext, but > ... you would still need a lot of support in there to get what you want. Currently the externally stored scripts get cached in a static HashMap, the page-related script manager and its script engines get cached and controlled via PageContext attributes and ThreadLocal. > What about cheating and just putting a Tag at the top-level where you have to > declare the > "version" of the script, and changing the "version" causes the cache to be > cleared? Ideally the user should not have to do that (to forgo user errors). ---rony --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
