On 21/06/2011 18:08, Simone Tripodi wrote:
Hi again,
that's not log4j but ant[1], it is easy&smart enough that could be
imported& modified depending on our needs...
And we could make it generic in the way we can reuse the same policy
also in all transformers that require an external resource to be load
(i.e. the XSchema validator)
Very nice idea, Simone (and Sylvain)!
Tomorrow I'll start importing that Watchdog class from ANT, then I'll
replace the current XSLT file caching mechanism with something using
this approach.
Let's see how this will go, and maybe we could extend it also to other
components, as you suggest above.
Since I will be using this modified XSLTTransformer anyway, it would be
much more practical to me not to be forced all the times to rebuild
cocoon 3 from sources on each and every place where I need it.
In simple words: is there any possibility to publish SNAPSHOT maven
artifacts somewhere?
Thanks.
On Tue, Jun 21, 2011 at 6:05 PM, Simone Tripodi
<simonetrip...@apache.org> wrote:
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/
