You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Donald Ball <ba...@webslingerZ.com> on 2001/05/08 21:30:58 UTC
[c2] still having caching problems
here's my sitemap:
<map:match pattern="*">
<map:aggregate element="root">
<map:part src="plain/meta"/>
<map:part src="plain/{1}"/>
</map:aggregate>
<map:transform type="xinclude"/>
<map:act type="resource-exists">
<parameter name="url" value="context://style/{1}.xsl"/>
<map:transform src="style/{../1}.xsl"/>
</map:act>
<map:select>
<map:when test="wap">
<map:transform src="style/wziml-wml.xsl"/>
<mal:serialize type="wap"/>
</map:when>
<map:otherwise>
<map:transform src="style/wziml-html.xsl"/>
<map:serialize type="html"/>
</map:otherwise>
</map:select>
</map:match>
<map:match pattern="plain/*">
<map:generate src="content/{1}.xml" type="serverpages"/>
<map:serialize/>
</map:match>
if i edit wziml-html.xsl, the first change is noticed and applied, but any
changes after that are not. the string 'wziml-html.xsl' does not appear in
cocoon.log anywhere, so there's nothing useful there to report.
personally, i consider this to be a show-stopper bug. no designer is going
to want to work on a system that requires the sysadmin to continually
restart tomcat to see changes.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] still having caching problems
Posted by Martin Man <Ma...@seznam.cz>.
On Wed, May 09, 2001 at 08:52:37AM +0100, Jeremy Quinn wrote:
> At 3:30 PM -0400 8/5/01, Donald Ball wrote:
> > <map:act type="resource-exists">
> > <parameter name="url" value="context://style/{1}.xsl"/>
> > <map:transform src="style/{../1}.xsl"/>
> > </map:act>
>
> Sorry if this is off-topic and I'm being real dumb .... but could someone
> explain what this bit does?
>
> OK, so it applies a stylesheet if it exists, but I do not understand the
> contents of these two attributes:
>
> value="context://style/{1}.xsl"
> src="style/{../1}.xsl"
>
> Why is there "{1}" in one and "{../1}" in the other?
{1} matches the star '*' within <map:act> scope meanwhile {../1} matches the
star within parent scope, (map:match here ???), although looking at the snipet
the {1} expr. here doesn't make any sense to me neither, seems like a typo
parameter value should be {../1} also... :-?
>
>
> Thanks for any help
>
>
> regards Jeremy
> --
> ___________________________________________________________________
>
> Jeremy Quinn Karma Divers
> webSpace Design
> HyperMedia Research Centre
>
> <ma...@mac.com> <http://www.media.demon.co.uk>
> <phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
-------------------------------------------------------------------------------
"Only dead fish swims with a stream"
gpg_key_available: http://globales.cz/~mman/martin.man.gpg
gpg_key_fingerprint: 2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] still having caching problems
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 9 May 2001, giacomo wrote:
> > the parameter element exists in the variable context of its parent, while
> > the map:transform element has its own unique variable context. the ../
> > prefix shifts the context up a level. i admit, it looks pretty silly, but
> > it gets the job done. although i'm tossing around the idea of adding an
> > attribute to the trax transformer:
> >
> > <map:transform src="style/{1}.xsl" optional="true"/>
> >
> > it's a thought.
>
> And whats the semantic of the "optional" attribute?
it would mean "if the stylesheet doesn't exist, keep going". perhaps more
generally it could mean "if any error occurs, keep going". the more i
think about it, the less i like it tho...
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] still having caching problems
Posted by giacomo <gi...@apache.org>.
On Wed, 9 May 2001, Donald Ball wrote:
> On Wed, 9 May 2001, Jeremy Quinn wrote:
>
> > At 3:30 PM -0400 8/5/01, Donald Ball wrote:
> > > <map:act type="resource-exists">
> > > <parameter name="url" value="context://style/{1}.xsl"/>
> > > <map:transform src="style/{../1}.xsl"/>
> > > </map:act>
> >
> > Sorry if this is off-topic and I'm being real dumb .... but could someone
> > explain what this bit does?
> >
> > OK, so it applies a stylesheet if it exists, but I do not understand the
> > contents of these two attributes:
> >
> > value="context://style/{1}.xsl"
> > src="style/{../1}.xsl"
> >
> > Why is there "{1}" in one and "{../1}" in the other?
>
> the parameter element exists in the variable context of its parent, while
> the map:transform element has its own unique variable context. the ../
> prefix shifts the context up a level. i admit, it looks pretty silly, but
> it gets the job done. although i'm tossing around the idea of adding an
> attribute to the trax transformer:
>
> <map:transform src="style/{1}.xsl" optional="true"/>
>
> it's a thought.
And whats the semantic of the "optional" attribute?
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] still having caching problems
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 9 May 2001, Jeremy Quinn wrote:
> At 3:30 PM -0400 8/5/01, Donald Ball wrote:
> > <map:act type="resource-exists">
> > <parameter name="url" value="context://style/{1}.xsl"/>
> > <map:transform src="style/{../1}.xsl"/>
> > </map:act>
>
> Sorry if this is off-topic and I'm being real dumb .... but could someone
> explain what this bit does?
>
> OK, so it applies a stylesheet if it exists, but I do not understand the
> contents of these two attributes:
>
> value="context://style/{1}.xsl"
> src="style/{../1}.xsl"
>
> Why is there "{1}" in one and "{../1}" in the other?
the parameter element exists in the variable context of its parent, while
the map:transform element has its own unique variable context. the ../
prefix shifts the context up a level. i admit, it looks pretty silly, but
it gets the job done. although i'm tossing around the idea of adding an
attribute to the trax transformer:
<map:transform src="style/{1}.xsl" optional="true"/>
it's a thought.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] still having caching problems
Posted by giacomo <gi...@apache.org>.
On Wed, 9 May 2001, Jeremy Quinn wrote:
> At 3:30 PM -0400 8/5/01, Donald Ball wrote:
> > <map:act type="resource-exists">
> > <parameter name="url" value="context://style/{1}.xsl"/>
> > <map:transform src="style/{../1}.xsl"/>
> > </map:act>
>
> Sorry if this is off-topic and I'm being real dumb .... but could someone
> explain what this bit does?
>
> OK, so it applies a stylesheet if it exists, but I do not understand the
> contents of these two attributes:
>
> value="context://style/{1}.xsl"
> src="style/{../1}.xsl"
>
> Why is there "{1}" in one and "{../1}" in the other?
It has to do with value substitution. I agree with you that the snipped
above dosn't make any sense concerning value substitution. Normally ie.
a matcher has a pattern attribute like pattern="foo/*". In this case the
matcher returns the value of the mached "*" back to the sitemap where
you can refer it in certain attribute like {1} inside the map:match
element. An action too can return
values back to the sitemap for substitution. Those components do that by
using a map. Matcher usually name their map entries 1, 2, ... actions
can use any names.
Now if you have the following:
<map:mact pattern="foo/*">
<map:act type="maAction">
<map:generate src="foo/{../1}/{action-value}"/>
...
</map:act>
</map:match>
the {action-value} refers to a name in the map returned by the action
whereas the {../1} refers to the matchers map. The syntax using ../ was
taken from the XPath syntax to refer to the map above the current one.
Hope this helped you to understand.
Giacomo
>
>
> Thanks for any help
>
>
> regards Jeremy
> --
> ___________________________________________________________________
>
> Jeremy Quinn Karma Divers
> webSpace Design
> HyperMedia Research Centre
>
> <ma...@mac.com> <http://www.media.demon.co.uk>
> <phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] still having caching problems
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 3:30 PM -0400 8/5/01, Donald Ball wrote:
> <map:act type="resource-exists">
> <parameter name="url" value="context://style/{1}.xsl"/>
> <map:transform src="style/{../1}.xsl"/>
> </map:act>
Sorry if this is off-topic and I'm being real dumb .... but could someone
explain what this bit does?
OK, so it applies a stylesheet if it exists, but I do not understand the
contents of these two attributes:
value="context://style/{1}.xsl"
src="style/{../1}.xsl"
Why is there "{1}" in one and "{../1}" in the other?
Thanks for any help
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] still having caching problems
Posted by Jason Foster <ja...@uwaterloo.ca>.
> if i edit wziml-html.xsl, the first change is noticed and applied, but any
> changes after that are not. the string 'wziml-html.xsl' does not appear in
> cocoon.log anywhere, so there's nothing useful there to report.
>
> personally, i consider this to be a show-stopper bug. no designer is going
> to want to work on a system that requires the sysadmin to continually
> restart tomcat to see changes.
I get similar behaviour using a pipeline as small as the basic "hello"
examples, and concur that this is a show-stopper.
The only solution I have come up with is to mess with the cache settings
in cocoon.xconf. If I set the objectlifetime, interval, and maxobjects to
"1", and usethread to "true", then I can test without a restart of tomcat
(subject to a 1-2 second delay of course).
Jason Foster
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [c2] still having caching problems
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Santiago Gala wrote:
>
> Carsten Ziegeler wrote:
>
> >>Donald Ball wrote:
> >>
> >>On Wed, 9 May 2001, Carsten Ziegeler wrote:
> >>
> >>
> >>>>if i edit wziml-html.xsl, the first change is noticed and
> >>>>
> >>applied, but any
> >>
> >>>>changes after that are not. the string 'wziml-html.xsl' does
> >>>>
> >>not appear in
> >>
> >>>>cocoon.log anywhere, so there's nothing useful there to report.
> >>>>
> >>>>personally, i consider this to be a show-stopper bug. no
> >>>>
> >>designer is going
> >>
> >>>>to want to work on a system that requires the sysadmin to continually
> >>>>restart tomcat to see changes.
> >>>>
> >>>>
> >>>You are absolutely right, this is a show stopper.
> >>>But in your example above, the whole pipeline for your pattern "*" is
> >>>not cached at all, as the aggregate component is not cacheable right
> >>>now (it declares cacheable, but returns "null" for the CacheValidity
> >>>object).
> >>>
> >>okay.
> >>
> >>
> >>>According to other reports, did you try to turn off the "use-store"
> >>>configuration of the TraxTransformer? There are some other reports,
> >>>that after turning this off, everything works fine.
> >>>
> >>argh, i must've skipped right over that parameter dozens of times now.
> >>yeah, if i set it to false, the problem goes away. makes sense. what
> >>classes are responsible for the transformer store?
> >>
> >>
> > As far as I know, the TraxTransformer, the used Store and some
> > Xalan classes. But I think the main logic is in the TraxTransformer
> > itself.
> >
>
>
> It smells :) like the TraxTransformer is not updating
> xslFileLastModified correctly. It only does this on setup().
>
> It uses xslFileLastModified for validity stuff, while it uses
> storedTime < xslFile.lastModified() for templates generation in
> getTemplates(), which is called independently of setup()...
>
> Also, this is only implemented for "file:" uri, while calatina, for
> instance, could generate "jndi:" uris, and websphere "classloader:" uris.
>
> Just two euro cents :)
>
>
Ups, yes indeed . This might be one cause for the problems.
I will fix it and we can see if this solves all.
Thanks,
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [c2] still having caching problems
Posted by Santiago Gala <sg...@hisitech.com>.
Carsten Ziegeler wrote:
>>Donald Ball wrote:
>>
>>On Wed, 9 May 2001, Carsten Ziegeler wrote:
>>
>>
>>>>if i edit wziml-html.xsl, the first change is noticed and
>>>>
>>applied, but any
>>
>>>>changes after that are not. the string 'wziml-html.xsl' does
>>>>
>>not appear in
>>
>>>>cocoon.log anywhere, so there's nothing useful there to report.
>>>>
>>>>personally, i consider this to be a show-stopper bug. no
>>>>
>>designer is going
>>
>>>>to want to work on a system that requires the sysadmin to continually
>>>>restart tomcat to see changes.
>>>>
>>>>
>>>You are absolutely right, this is a show stopper.
>>>But in your example above, the whole pipeline for your pattern "*" is
>>>not cached at all, as the aggregate component is not cacheable right
>>>now (it declares cacheable, but returns "null" for the CacheValidity
>>>object).
>>>
>>okay.
>>
>>
>>>According to other reports, did you try to turn off the "use-store"
>>>configuration of the TraxTransformer? There are some other reports,
>>>that after turning this off, everything works fine.
>>>
>>argh, i must've skipped right over that parameter dozens of times now.
>>yeah, if i set it to false, the problem goes away. makes sense. what
>>classes are responsible for the transformer store?
>>
>>
> As far as I know, the TraxTransformer, the used Store and some
> Xalan classes. But I think the main logic is in the TraxTransformer
> itself.
>
It smells :) like the TraxTransformer is not updating
xslFileLastModified correctly. It only does this on setup().
It uses xslFileLastModified for validity stuff, while it uses
storedTime < xslFile.lastModified() for templates generation in
getTemplates(), which is called independently of setup()...
Also, this is only implemented for "file:" uri, while calatina, for
instance, could generate "jndi:" uris, and websphere "classloader:" uris.
Just two euro cents :)
> Carsten
>
>>- donald
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>>For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [c2] still having caching problems
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Donald Ball wrote:
>
> On Wed, 9 May 2001, Carsten Ziegeler wrote:
>
> > > if i edit wziml-html.xsl, the first change is noticed and
> applied, but any
> > > changes after that are not. the string 'wziml-html.xsl' does
> not appear in
> > > cocoon.log anywhere, so there's nothing useful there to report.
> > >
> > > personally, i consider this to be a show-stopper bug. no
> designer is going
> > > to want to work on a system that requires the sysadmin to continually
> > > restart tomcat to see changes.
> > >
> > You are absolutely right, this is a show stopper.
> > But in your example above, the whole pipeline for your pattern "*" is
> > not cached at all, as the aggregate component is not cacheable right
> > now (it declares cacheable, but returns "null" for the CacheValidity
> > object).
>
> okay.
>
> > According to other reports, did you try to turn off the "use-store"
> > configuration of the TraxTransformer? There are some other reports,
> > that after turning this off, everything works fine.
>
> argh, i must've skipped right over that parameter dozens of times now.
> yeah, if i set it to false, the problem goes away. makes sense. what
> classes are responsible for the transformer store?
>
As far as I know, the TraxTransformer, the used Store and some
Xalan classes. But I think the main logic is in the TraxTransformer
itself.
Carsten
> - donald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [c2] still having caching problems
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 9 May 2001, Carsten Ziegeler wrote:
> > if i edit wziml-html.xsl, the first change is noticed and applied, but any
> > changes after that are not. the string 'wziml-html.xsl' does not appear in
> > cocoon.log anywhere, so there's nothing useful there to report.
> >
> > personally, i consider this to be a show-stopper bug. no designer is going
> > to want to work on a system that requires the sysadmin to continually
> > restart tomcat to see changes.
> >
> You are absolutely right, this is a show stopper.
> But in your example above, the whole pipeline for your pattern "*" is
> not cached at all, as the aggregate component is not cacheable right
> now (it declares cacheable, but returns "null" for the CacheValidity
> object).
okay.
> According to other reports, did you try to turn off the "use-store"
> configuration of the TraxTransformer? There are some other reports,
> that after turning this off, everything works fine.
argh, i must've skipped right over that parameter dozens of times now.
yeah, if i set it to false, the problem goes away. makes sense. what
classes are responsible for the transformer store?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [c2] still having caching problems
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Donald Ball wrote:
>
> here's my sitemap:
>
> <map:match pattern="*">
> <map:aggregate element="root">
> <map:part src="plain/meta"/>
> <map:part src="plain/{1}"/>
> </map:aggregate>
> <map:transform type="xinclude"/>
> <map:act type="resource-exists">
> <parameter name="url" value="context://style/{1}.xsl"/>
> <map:transform src="style/{../1}.xsl"/>
> </map:act>
> <map:select>
> <map:when test="wap">
> <map:transform src="style/wziml-wml.xsl"/>
> <mal:serialize type="wap"/>
> </map:when>
> <map:otherwise>
> <map:transform src="style/wziml-html.xsl"/>
> <map:serialize type="html"/>
> </map:otherwise>
> </map:select>
> </map:match>
>
> <map:match pattern="plain/*">
> <map:generate src="content/{1}.xml" type="serverpages"/>
> <map:serialize/>
> </map:match>
>
> if i edit wziml-html.xsl, the first change is noticed and applied, but any
> changes after that are not. the string 'wziml-html.xsl' does not appear in
> cocoon.log anywhere, so there's nothing useful there to report.
>
> personally, i consider this to be a show-stopper bug. no designer is going
> to want to work on a system that requires the sysadmin to continually
> restart tomcat to see changes.
>
You are absolutely right, this is a show stopper.
But in your example above, the whole pipeline for your pattern "*" is
not cached at all, as the aggregate component is not cacheable right
now (it declares cacheable, but returns "null" for the CacheValidity
object).
According to other reports, did you try to turn off the "use-store"
configuration of the TraxTransformer? There are some other reports,
that after turning this off, everything works fine.
If I am able to reproduce the problem (which I am currently unfortunately
not)
I will have a look at it.
Carsten
> - donald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org