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

Reply via email to