You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Francesco Chicchiriccò <il...@apache.org> on 2011/06/21 17:50:38 UTC
[C3] XSLTTransformer cache
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/
Re: [C3] XSLTTransformer cache
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 22/06/2011 17:39, Francesco Chicchiriccò wrote:
> 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.
Today I've been actually working on this topic, but the Watchdog class
seemed to me too heavy for our purpose.
Basically, it would start a separate thread for each XSLT source
processed; each thread will be sleeping for some time, then awake and
reload the XSLT source.
I considered that in most cases the XSLT source is a plain XSLT file,
and that when this does not apply, the XSLT source can be considered
rather immutable.
Hence, I've extended the current caching approach used in
XSLTTransformer and SchemaProcessorTransformer with the capability to
take into account File.lastModified() when dealing with the cache. Of
course only when the source is a local file.
All tests (including it.sh) run successfully and the feature I needed -
be able to work with XSLT files on a running application - is working as
well.
For more details, you can take a look at revision 1138969.
Regards.
--
Francesco Chicchiriccò
Apache Cocoon Committer and PMC Member
http://people.apache.org/~ilgrosso/
Re: [C3] XSLTTransformer cache
Posted by Francesco Chicchiriccò <il...@apache.org>.
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
> <si...@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ò<il...@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/
Re: [C3] XSLTTransformer cache
Posted by Sylvain Wallez <sy...@apache.org>.
Le 21/06/11 18:08, Simone Tripodi a écrit :
> Hi again,
> that's not log4j but ant[1], it is easy&smart enough that could be
> imported& modified depending on our needs...
Commons IO also has a file monitor that was written by Torsten :
http://commons.apache.org/io/
There's also http://jnotify.sourceforge.net/ that uses native services
such as inotify on Linux, which should be more efficient by avoiding
polling, but I haven't tried it and it depends on native libraries.
> 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)
That's a very good idea. Checking the file at each and every use can
lead to a lot of requests to the filesystem on a loaded system, to check
files that actually don't move that often. So doing it in the background
adds some complexity but can allow hot reloading on a live system
without hurting much performances.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [C3] XSLTTransformer cache
Posted by Simone Tripodi <si...@apache.org>.
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)
HTH!
Simo
[1] http://svn.apache.org/repos/asf/ant/core/trunk/src/main/org/apache/tools/ant/util/Watchdog.java
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Jun 21, 2011 at 6:05 PM, Simone Tripodi
<si...@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ò <il...@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/
>>
>>
>
Re: [C3] XSLTTransformer cache
Posted by Simone Tripodi <si...@apache.org>.
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ò <il...@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/
>
>