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] > >
