I agree :-) On Fri, Nov 11, 2011 at 2:20 PM, Peter Ertl <[email protected]> wrote: > CachingResourceVersion is not an interface but a concrete, non-final class so > adding a method should be valid afaik > > Do you agree? > > Am 11.11.2011 um 13:16 schrieb Martin Grigorov: > >> On Fri, Nov 11, 2011 at 1:46 PM, Peter Ertl <[email protected]> wrote: >>> We could add... >>> >>> CachingResourceVersion#invalidateResource(IResourceVersion) >>> >>> adding methods is api-compatible, right? >> >> Adding methods to interfaces which the user might implement is not >> because she will have to implement this new method to fix her build. >> >> Just run: mvn clirr:check and it will tell you if there is something wrong. >> >>> >>> Cheers >>> Peter >>> >>> >>> Am 11.11.2011 um 09:09 schrieb Martin Grigorov: >>> >>>> Hi, >>>> >>>> On Fri, Nov 11, 2011 at 12:46 AM, Dominik Drzewiecki >>>> <[email protected]> wrote: >>>>> Howdy, >>>>> >>>>> I've been loooking carefully at what's new in wicket 1.5 and how its >>>>> concepts map to the earlier versions. >>>>> I've been particularly interested in how resource managment had been >>>>> given much care in 1.5. >>>>> One great feature is consistent resource id suffix generation. I have >>>>> however found an issue that may lead to a performace hit. >>>>> >>>>> It is advised to use MessageDigestResourceVersion rather than the >>>>> default LastModifiedResourceVersion in production environments, >>>>> especially clustered ones. Thus the following code present in >>>>> application init() method: >>>>> >>>>> getResourceSettings().setCachingStrategy( >>>>> new >>>>> FilenameWithVersionResourceCachingStrategy( >>>>> new >>>>> MessageDigestResourceVersion())); >>>>> >>>>> This however is highly ineficient as each and every access to any >>>>> resource (resource link generation, in fact) results in message digest >>>>> computation, regardless whether it is going to be sent back to the >>>>> browser or not. Lets wrap the MessageDigestResourceVersion with >>>>> CachingResourceVersion then: >>>>> >>>>> getResourceSettings().setCachingStrategy( >>>>> new >>>>> FilenameWithVersionResourceCachingStrategy( >>>>> new >>>>> CachingResourceVersion(new MessageDigestResourceVersion()))); >>>> >>>> This looks OK. >>>> >>>>> >>>>> Aha! Much better? Not exactly. Now the message digest will be computed >>>>> just once, and will stay in a cache for the lifetime of the >>>>> application. Whenever resource changes, the browser might be confused >>>>> to use stale cached version rather than request a new resource (Yes, >>>>> we do substitute context resources during runtime). >>>> >>>> In production resources don't change that often. It is not that common >>>> to substitute resources in production. >>>> >>>>> >>>>> It'd be nice to have some IResourceVersion implementation that caches >>>>> the computed resource version for some preconfigured period of time or >>>>> recalculates it on every n-th access. Or is triggeerd by some more >>>>> complex rule. >>>>> >>>>> getResourceSettings().setCachingStrategy( >>>>> new >>>>> FilenameWithVersionResourceCachingStrategy( >>>>> new >>>>> UpdateableCachingResourceVersion(new >>>>> MessageDigestResourceVersion(), new Or(new AccessedMoreThan(5), new >>>>> OlderThan(30000))))); >>>> >>>> For your use case this will be the best but for the common case just >>>> CachingResourceVersion should be enough, IMO. >>>> >>>>> >>>>> If you find it worth putting into core, I can file a jira issue and >>>>> provide an appropriate patch. >>>> >>>> Sure, do it! >>>> >>>>> >>>>> regz, >>>>> /dd >>>>> >>>>> -- >>>>> /* Spelin donut mader if iz ina coment */ >>>>> >>>> >>>> >>>> >>>> -- >>>> Martin Grigorov >>>> jWeekend >>>> Training, Consulting, Development >>>> http://jWeekend.com >>> >>> >> >> >> >> -- >> Martin Grigorov >> jWeekend >> Training, Consulting, Development >> http://jWeekend.com > >
-- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
