Fair enough. I also see that in deployment mode wicket actually caches the decorated url of resources for the entire application lifetime, so the Resource.getCacheableResourceStream isn't repeated each time a page is rendered with a reference to a resource.
On Tue, Mar 26, 2013, at 2:09, Dan Retzlaff wrote: > I believe Wicket's resource versioning and caching logic simply provides > advice in HTTP response headers, and decorates filenames if so > configured. > Do your requests come directly to Wicket's container? We reverse proxy > with > HTTPD, which is probably better at caching than a Java solution could > ever > be. > > On Mon, Mar 25, 2013 at 5:01 PM, Pointbreak > <[email protected]>wrote: > > > I have implemented a LessCssResource (it generates a CSS resource from > > Less source files) + LessCssResourceReference. Since computing the CSS > > is expensive, I would like to cache the generated CSS on the server, > > once generated. It is unclear to me whether Wicket has mechanisms to do > > this. I expected that IStaticCacheableResource would also provide the > > means to do server side caching (in addition to setting the correct > > headers and decorating the url for client-side caching). But this > > doesn't seem to be the case. > > > > When I look at what happens when doing a second page request/refresh > > after all browser caches are cleared, it seems that for IResource's that > > implement IStaticCacheableResource (including my LessCssResource, but > > also e.g. ConcatBundleResource from wicket core): > > > > * Resource.newResourceResponse is called (which obviously results in a > > recompute of the entire response) > > * Resource.getCacheableResourceStream is called (which also does a > > recompute of the entire response) > > * All implementations of these methods in wicket core resources are > > designed so that both calls do a full recompute of the actual response > > (which duplicates the effort for every page that uses a resource) > > * The Resource itself is recreated for every request (I could cache it > > in e.g. LessCssResourceReference, but nothing in wicket core abuses > > ResourceReferences for server side caching of Resources, so I'd like to > > know if there is a better approach). > > > > I have looked at Wickets own implementations of Resources that would > > benefit from server side caching and happen to implement > > IStaticCachableResource (e.g. ConcatBundleResource) and they seem to > > have the same behaviour: no server-side caching, and for each request > > the resource is actually computed multiple times: once for the actual > > response, once for computing the cache-key to decorate the url. > > > > Hence I would like to know: > > > > * Should the duplicate expensive compute of various Wicket core > > IStaticCacheableResource implementations not be fixed? > > * Does Wicket provide any mechanism for server side caching of IResource > > implementations? > > > > Thanks > > > > --------------------------------------------------------------------- > > 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]
