Hi Grosso, of course, COCOON3-62 is still valid, I should have resolved it before the alpha-3, but "maybe" I'm in too much things now... :P Feel free to work on it!
Anyway, we didn't implement the cache with the policy you suggested because there was an original idea - suggested by Sylvain - that the transformer should be take care about checking file modification and reloading the XSLT if changed. So I'd proceed to a Watchdog implementation - it could be kindly borrowed from already existing Apache components (log4j has one if I'm not wrong, I'll give a search anyway) - rather than a pure cache policy: immagine changes are frequent, they could - in the WOOOOOOOORSe case of course - pull out from the LRU also other XSL... WDYT? just my 2 cents, have a nice day!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ 2011/6/21 Francesco Chicchiriccò <ilgro...@apache.org>: > Hi folks, > I am playing quite a lot these days with Cocoon 3 because I had the insane > idea to build a CMS frontend framework upon its solid foundations :-) > > Among other things (for which I'll write some other e-mails), I see that the > XSLTTransformer is currently implemented with a LRU cache using the sole > filename as key. This would imply that XSLT files get never reloaded, even > such feature would be extremely useful when developing XSLT. > > What do you think if I modify the current XSLTTransformer cache mechanism in > order to have a more complex key (say filename + filesize)? > > Anyway, do you think that [1] is still valid? > > [1] https://issues.apache.org/jira/browse/COCOON3-62 > > -- > Francesco Chicchiriccò > > Apache Cocoon Committer and PMC Member > http://people.apache.org/~ilgrosso/ > >
