Re: [Xforge-users] New Feature implemented: FilesMonitor

[Ulrich M. <ul...@de...>]

Alberto Garoffolo wrote:
> Hhmmm .... probably i didn' t got the point ....
> Why do u need to have a unique identifier associated with the current
> resource?
> Monitors are already handled by the MonitorsManager which after a request is
> processed starts a context containing all the monitors needed to "monitor"
> components used, according to the context class specified by the current
> request
> context
> (see XForgeC2URLContext / XForgeC1URLContext / XForgeTestURLContext).
> 
> Perhaps i misunderstood ....

In the XSLComponent I need to know an identifier for the current XML 
resource being processed. Because if that identifier is a file (I test 
for that), then I have to return a FilesMonitor, which monitors both 
files (the XML file and the stylesheet) for modifications.

For example, run this test:

./run.sh test/XSLT.xml test/result.xml 100000 true

Then during the run do:
touch test/XSLT.xml
touch test/test.xsl

You will see in xforge.log (grep xforge.log "isn't changed"|wc -l) that 
each touch is picked up correctly by the monitoring system. The 
component is run three times altogether: The first time during the very 
first invocation. Then after the touch to the XML file, then again after 
the touch to the stylesheet.

If, however, you change in Test.java this line:

broker.putObject(threadcontext,"testfile",src);

to something like:

broker.putObject(threadcontext,"testfile","ThisIsNoFile");

and redo the same test, you will find that the monitoring system only 
picks up the touch to the stylesheet. This is because the XSL component 
found that "ThisIsNoFile" is not a file and so cannot return a Monitor 
for it.

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung