done! see https://issues.apache.org/jira/browse/WICKET-4218
Am 11.11.2011 um 13:24 schrieb Martin Grigorov: > 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
