You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2005/01/13 16:35:23 UTC
i18n catalogues and caching
Hello,
this is my first post for the new company I work for - and I have a problem with
the caching of the i18n catalogues. The location of one i18n catalogue is
defined to be dependent on {request-attr:xyz}, so it can change on each request.
But the first access to this i18n transformer caches the catalogue and its
location, later accesses to the transformer will not have the correct catalogues
available. Is it possible to either prevent the caching of the catalogues at all
or - even better - to influence the caching by adding the dependency on the
request attribute?
Thanks,
Joerg
Re: i18n catalogues and caching
Posted by Ralph Goers <Ra...@dslextreme.com>.
Joerg Heinicke said:
> Did it and found the reason - and a work around. It's not
> I18nTransformer's
> fault, but the one of XMLResourceBundleFactory: It's creating a hierarchy
> of
> XMLResourceBundle's, which have a parent relation to another
> XMLResourceBundle.
> The bundles are cached by filenames, with the declaration like above it's
> "../resources/translations". So independent on the latter locations always
> the
> cached bundle for the first location is returned. The work around is
> obviously
> to change the order of the locations from the specific to the common one.
> But it's still a strange behaviour, the hierarchy is not obvious for the
> user,
> it's more a list of locations. Therefore the current behaviour and the
> workaround should not only be well-documented, but also changed.
Well, its nice to see that someone else is using the multiple location
stuff I added. I believe at the time I added this that catalogues were
permanently cached. I recall someone adding support right after that for
reloading them after they were modified. I guess I assumed that this was
done on a per file basis as even a catalogue in a single location can
consist of multiple files.
Ralph
Re: i18n catalogues and caching
Posted by Joerg Heinicke <jo...@gmx.de>.
Reinhard Poetz <reinhard <at> apache.org> writes:
> > <map:transformer logger="sitemap.transformer.i18n.todo" name="i18n"
> > src="org.apache.cocoon.transformation.I18nTransformer">
> > <catalogues default="dictionary">
> > <catalogue id="dictionary" location="resources/translations"
> > name="dictionary"/>
> > <catalogue id="todo" name="todo">
> > <location>../resources/translations</location>
> > <location>resources/translations</location>
> > <location>{request-attr:group}/resources/translations</location>
> > </catalogue>
> > <catalogue id="page" location="../resources/translations" name="page"/>
> > </catalogues>
> > <cache-at-startup>false</cache-at-startup>
> > </map:transformer>
> >
> > Any further idea?
>
> Not a specif one. I'd use the debugger or add some logging statements to find
> out where the I18nTransformer is actually looking for the catalogues.
Did it and found the reason - and a work around. It's not I18nTransformer's
fault, but the one of XMLResourceBundleFactory: It's creating a hierarchy of
XMLResourceBundle's, which have a parent relation to another XMLResourceBundle.
The bundles are cached by filenames, with the declaration like above it's
"../resources/translations". So independent on the latter locations always the
cached bundle for the first location is returned. The work around is obviously
to change the order of the locations from the specific to the common one.
But it's still a strange behaviour, the hierarchy is not obvious for the user,
it's more a list of locations. Therefore the current behaviour and the
workaround should not only be well-documented, but also changed.
Joerg
Re: i18n catalogues and caching
Posted by Reinhard Poetz <re...@apache.org>.
Joerg Heinicke wrote:
> Reinhard Poetz <reinhard <at> apache.org> writes:
>
>
>>>>I have a problem with the caching of the i18n catalogues.
>>>
>>>Any idea what can go wrong?
>>
>>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110064557022481&w=2 - maybe
>>the 4th paragraph gives some hint ...
>
>
> Thanks for the hint, it was an interesting read - I'm somewhat behind with my
> mails, around July last year ...
>
> But unfortunately it is not helping here:
> 1. The declaring sitemap ist the same as the using sitemap.
> 2. It's not a problem of resolving relative paths.
>
> declaration:
>
> <map:transformer logger="sitemap.transformer.i18n.todo" name="i18n"
> src="org.apache.cocoon.transformation.I18nTransformer">
> <catalogues default="dictionary">
> <catalogue id="dictionary" location="resources/translations"
> name="dictionary"/>
> <catalogue id="todo" name="todo">
> <location>../resources/translations</location>
> <location>resources/translations</location>
> <location>{request-attr:group}/resources/translations</location>
> </catalogue>
> <catalogue id="page" location="../resources/translations" name="page"/>
> </catalogues>
> <cache-at-startup>false</cache-at-startup>
> </map:transformer>
>
> usage:
>
> <map:match pattern="*/todo-*.pfm">
> <!-- action that puts request parameters into request attributes -->
> <map:act type="request-propagator">
> <map:parameter name="group" value="{1}"/>
> </map:act>
> <map:generate type="serverpages" src="{../1}/todo-{../2}.xml"/>
> ...
> <map:transform type="i18n">
> <map:parameter name="default-catalogue-id" value="todo"/>
> </map:transform>
> <map:serialize />
> </map:match>
>
> Any further idea?
Not a specif one. I'd use the debugger or add some logging statements to find
out where the I18nTransformer is actually looking for the catalogues.
--
Reinhard
Re: i18n catalogues and caching
Posted by Joerg Heinicke <jo...@gmx.de>.
Reinhard Poetz <reinhard <at> apache.org> writes:
> >>I have a problem with the caching of the i18n catalogues.
> >
> > Any idea what can go wrong?
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110064557022481&w=2 - maybe
> the 4th paragraph gives some hint ...
Thanks for the hint, it was an interesting read - I'm somewhat behind with my
mails, around July last year ...
But unfortunately it is not helping here:
1. The declaring sitemap ist the same as the using sitemap.
2. It's not a problem of resolving relative paths.
declaration:
<map:transformer logger="sitemap.transformer.i18n.todo" name="i18n"
src="org.apache.cocoon.transformation.I18nTransformer">
<catalogues default="dictionary">
<catalogue id="dictionary" location="resources/translations"
name="dictionary"/>
<catalogue id="todo" name="todo">
<location>../resources/translations</location>
<location>resources/translations</location>
<location>{request-attr:group}/resources/translations</location>
</catalogue>
<catalogue id="page" location="../resources/translations" name="page"/>
</catalogues>
<cache-at-startup>false</cache-at-startup>
</map:transformer>
usage:
<map:match pattern="*/todo-*.pfm">
<!-- action that puts request parameters into request attributes -->
<map:act type="request-propagator">
<map:parameter name="group" value="{1}"/>
</map:act>
<map:generate type="serverpages" src="{../1}/todo-{../2}.xml"/>
...
<map:transform type="i18n">
<map:parameter name="default-catalogue-id" value="todo"/>
</map:transform>
<map:serialize />
</map:match>
Any further idea?
Joerg
Re: i18n catalogues and caching
Posted by Reinhard Poetz <re...@apache.org>.
Joerg Heinicke wrote:
> Joerg Heinicke <joerg.heinicke <at> gmx.de> writes:
>
>
>>I have a problem with
>>the caching of the i18n catalogues. The location of one i18n catalogue is
>>defined to be dependent on {request-attr:xyz}, so it can change on each
>>request. But the first access to this i18n transformer caches the catalogue
>>and its location, later accesses to the transformer will not have the correct
>>catalogues available. Is it possible to either prevent the caching of the
>>catalogues at all or - even better - to influence the caching by adding the
>>dependency on the request attribute?
>
>
> I had a look into the code - and the JavaDoc describes the behaviour it should
> have and I want to have, but it obviously does not have:
>
> JavaDoc for CatalogueInfo (inner class of I18nTransformer):
> "Holds information about one catalogue. The location and name of the catalogue
> can contain references to input modules, and are resolved upon each transformer
> usage. It is important that releaseCatalog is called when the transformer is
> recycled."
>
> Any idea what can go wrong?
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110064557022481&w=2 - maybe the
4th paragraph gives some hint ...
--
Reinhard
Re: i18n catalogues and caching
Posted by Joerg Heinicke <jo...@gmx.de>.
Joerg Heinicke <joerg.heinicke <at> gmx.de> writes:
> I have a problem with
> the caching of the i18n catalogues. The location of one i18n catalogue is
> defined to be dependent on {request-attr:xyz}, so it can change on each
> request. But the first access to this i18n transformer caches the catalogue
> and its location, later accesses to the transformer will not have the correct
> catalogues available. Is it possible to either prevent the caching of the
> catalogues at all or - even better - to influence the caching by adding the
> dependency on the request attribute?
I had a look into the code - and the JavaDoc describes the behaviour it should
have and I want to have, but it obviously does not have:
JavaDoc for CatalogueInfo (inner class of I18nTransformer):
"Holds information about one catalogue. The location and name of the catalogue
can contain references to input modules, and are resolved upon each transformer
usage. It is important that releaseCatalog is called when the transformer is
recycled."
Any idea what can go wrong?
Joerg
Re: i18n catalogues and caching
Posted by Joerg Heinicke <jo...@gmx.de>.
Sylvain Wallez <sylvain <at> apache.org> writes:
> > I have a problem with the caching of the i18n catalogues. The location of
> > one i18n catalogue is defined to be dependent on {request-attr:xyz}, so it
> > can change on each request.
> > But the first access to this i18n transformer caches the catalogue and its
> > location, later accesses to the transformer will not have the correct
> > catalogues available. Is it possible to either prevent the caching of the
> > catalogues at all or - even better - to influence the caching by adding the
> > dependency on the request attribute?
>
> This seems to be related to the CatalogueInfo class in the
> I18nTransformer that holds the location of a catalogue. This class holds
> a VariableResolver, the object used in the sitemap engine to resolve
> {...} variables, which is resolved at the *first* use of a catalogue,
> and is never reevaluated again later.
>
> So that means that when using {request-attr:xyz} in the catalogue
> location, this expression is evaluated only at the first request where
> this catalogue is used.
>
> A solution would be for catalogue locations to be evaluated at each
> request, e.g. in the transformer's setup() method, or at the first use
> of a catalogue within a setup()/recycle() cycle.
No, CatalogueInfo is not the problem. The variables are resolved on each
request. But the bundles returned by the (String[] directories, ...) in
XMLResourceBundleFactory is always the same though the String[] directories are
different. The first directory in the String[] is evaluated and taken from cache
- with all the other bundles attached as parents.
Joerg
Re: i18n catalogues and caching
Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
>Hello,
>
>this is my first post for the new company I work for - and I have a problem with
>the caching of the i18n catalogues. The location of one i18n catalogue is
>defined to be dependent on {request-attr:xyz}, so it can change on each request.
>But the first access to this i18n transformer caches the catalogue and its
>location, later accesses to the transformer will not have the correct catalogues
>available. Is it possible to either prevent the caching of the catalogues at all
>or - even better - to influence the caching by adding the dependency on the
>request attribute?
>
>
This seems to be related to the CatalogueInfo class in the
I18nTransformer that holds the location of a catalogue. This class holds
a VariableResolver, the object used in the sitemap engine to resolve
{...} variables, which is resolved at the *first* use of a catalogue,
and is never reevaluated again later.
So that means that when using {request-attr:xyz} in the catalogue
location, this expression is evaluated only at the first request where
this catalogue is used.
A solution would be for catalogue locations to be evaluated at each
request, e.g. in the transformer's setup() method, or at the first use
of a catalogue within a setup()/recycle() cycle.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }