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
