You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Yves Zoundi <yv...@bibl.ulaval.ca> on 2006/07/11 21:54:59 UTC
Re: Localization and caching SOLVED
Thanks again Ard and Bertrand.!
Clearing the cache was the solution. Cocoon 2.1.9 does seem to be
stable enough. I am having problems with dynamic errors when doing some
xsl transformations. It doesn`t happen all the time but I can not put
that into production. Hopefully it is a problem I can solve by mysef. I
am using saxon8 as default xsl processor because it is faster. I will
try downgrading to saxon 6.5.5 and use cocoon 2.1.8 to see if there are
any changes.
Thanks again.
Ard Schrijvers a écrit :
>> Thanks again,
>>
>> I set the parameter use-locale to true and it is still
>> not working.
>>
>
> Did you restart cocoon and clear the cache?
>
>
>> What I still don't understand is that when I don't use
>> a pipeline which
>> type is caching or event-awrare everything is working fine! I
>> change the
>> locale and it is reflected in all the application web pages.
>> I wonder if
>> it is the caching mecanism or cache configuration that I am missing.
>>
>
> No, there cannot be something configured wrong...For example, if you replace {../language} by first "fr" and then "en" you will see it just works. Try to clear your cache, and do the statusGenerator. did you do that? You will see a key. This is a pipeline key, composed of all cacheable components in your pipeline. It ends with the i18n transformer, in which you really should see the locale.
>
> Again, did you restart cocoon? Set the
>
>
>>> <create-session>true</create-session>
>>> <store-in-request>true</store-in-request>
>>> <store-in-session>true</store-in-session>
>>>
>
> all to false...ok? It is indeed trange that it works without caching, but therefor, mail the cachekeys generated. They should speak fo themselves
>
> Ard
>
>
>> Any clue
>>
>>
>> On Tue, 2006-07-11 at 17:51 +0200, Ard Schrijvers wrote:
>>
>>> You are explicitly telling LocaleAction not to use the locale!
>>>
>>> set <use-locale>true</use-locale>, and restart your app.
>>>
>>> Now, try with mozilla and explorer and make sure they have
>>>
>> a different lang setting. You will see different responses,
>> and cachekeys for each language.
>>
>>> Regards Ard
>>>
>>> ps why are you having :
>>>
>>> <create-session>true</create-session>
>>> <store-in-request>true</store-in-request>
>>> <store-in-session>true</store-in-session>
>>>
>>> I dunno exactly where it is for, but do you have a reason
>>>
>> to set them to true??
>>
>>> Regards Ard
>>>
>>>
>>>> Hi Ard,
>>>>
>>>> Here is a sitemap.xmap sample of what I am using in the
>>>> application.
>>>>
>>>> Thanks again for your time
>>>>
>>>> On Tue, 2006-07-11 at 16:09 +0200, Ard Schrijvers wrote:
>>>>
>>>>> By default the locale in i18n is added to the cachekey.
>>>>>
>>>>> When you have your sitemap (snippet) ready I can take a look,
>>>>>
>>>>> Regards Ard
>>>>>
>>>>>> Hello again,
>>>>>>
>>>>>> I am looking deeper into my sitemap.xmap configuration
>>>>>> and I can't
>>>>>> figure out what is going on. I will trying looking into
>>>>>>
>>>> the caching
>>>>
>>>>>> details and the cocoon internals. The locale value might not
>>>>>> even be in
>>>>>> the Apache Cocoon context parameters.
>>>>>> I will try to print it tnin the XSL stylesheet to check
>>>>>> if the locale
>>>>>> value is present in the Apache Cocoon context.
>>>>>> I will send you ca copy of my sitemap.xmap as soon as I
>>>>>> am done with
>>>>>> some modifications.
>>>>>>
>>>>>> Thanks again.
>>>>>>
>>>>>> On Tue, 2006-07-11 at 09:27 +0200, Ard Schrijvers wrote:
>>>>>>
>>>>>>>> Hi Ard,
>>>>>>>>
>>>>>>>> I remove the <use-request-parameters> instructions
>>>>>>>> everywhere and it is
>>>>>>>> still not working.
>>>>>>>>
>>>>>>> It wasn't a solution to your problem, but merely a general
>>>>>>>
>>>>>> warning for everybody :-)
>>>>>>
>>>>>>>> With the status generator, I can see what Cocoon
>>>>>>>>
>> is holding
>>
>>>>>>>> in the Cache,
>>>>>>>> but It doesn't seem to hold any key like locale.
>>>>>>>>
>>>>>>> Well, there is then the problem
>>>>>>>
>>>>>>>
>>>>>>>> Here is what I tried :
>>>>>>>> - I added a virtual parameter called "foo" which
>>>>>>>>
>> contained the
>>
>>>>>>>> localization parameters
>>>>>>>> <map:parameter name = "foo" value = "{../locale}"/>
>>>>>>>>
>>>>>>> if {../locale} contains a value it should be
>>>>>>>
>> visible in cachekey
>>
>>>>>>>> - I tried adding a virtual parameter called locale in the
>>>>>>>> XSLT transformer
>>>>>>>> where I don't use it
>>>>>>>> <map:transform src = "stylesheet.xsl">
>>>>>>>> <map:parameter name = "foo" value = "{../locale}"/>
>>>>>>>> </map:transform>
>>>>>>>>
>>>>>>> Should also be visible in cachekey
>>>>>>>
>>>>>>>
>>>>>>>> - I tried modifying the pipeline parameters to introduce
>>>>>>>>
>>>>>> a parameter
>>>>>>
>>>>>>>> called cache-key
>>>>>>>> <map:pipeline type = "caching">
>>>>>>>> <map:parameter name = "cache-key" value =
>>>>>>>>
>>>>>> "{session:attr-locale}"/>
>>>>>>
>>>>>>> no, this only works for expiring pipelines in this way.
>>>>>>>
>>>>>> Does {session:attr-locale} contain the locale?
>>>>>>
>>>>>>>> ...
>>>>>>>> </map:pipeline>
>>>>>>>>
>>>>>>>> None of those solutions seem to work. I am thinking about
>>>>>>>>
>>>>>> switching to
>>>>>>
>>>>>>>> something else but with all the work I have done
>>>>>>>>
>> with Cocoon,
>>
>>>>>>>> I don't want
>>>>>>>> to do it.
>>>>>>>>
>>>>>>> I wouldn't want that either. Do you mind sending me
>>>>>>>
>>>>>> (a.schrijvers at hippo.nl) your sitemap? I will take a look
>>>>>> and help you out.
>>>>>>
>>>>>>> Regards Ard
>>>>>>>
>>>>>>>
>>>>>>>> What I suspect is that Cocoon is caching
>>>>>>>>
>> everything from the
>>
>>>>>>>> instruction
>>>>>>>> map:act :
>>>>>>>> <map:pipeline>
>>>>>>>> <map:act type = "locale">
>>>>>>>> <map:match pattern = "index.xml"/>
>>>>>>>> <map:generate src = "index.xsl"/>
>>>>>>>> <map:transform type = "i18n">
>>>>>>>> <map:parameter name = "locale" value = "{../locale}"/>
>>>>>>>> </map:transform>
>>>>>>>> </map:act>
>>>>>>>> </map:pipeline>
>>>>>>>>
>>>>>>>> So I think that when I request a page, Cocoon
>>>>>>>>
>> just take the
>>
>>>>>>>> content in the
>>>>>>>> cache without thinking of the locale attribute in
>>>>>>>>
>> the i18n
>>
>>>>>>>> transformer. So
>>>>>>>> the locale is not the cachekey and is never defined
>>>>>>>>
>>>>>> explicitly in the
>>>>>>
>>>>>>>> cache(StatusGenerator).
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks again for your help.
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: "Ard Schrijvers" <a....@hippo.nl>
>>>>>>>> To: <us...@cocoon.apache.org>
>>>>>>>> Date: Sun, 9 Jul 2006 12:07:56 +0200
>>>>>>>> Subject: RE: Localization and caching
>>>>>>>>
>>>>>>>>
>>>>>>>>>> Thanks a lot Ard!
>>>>>>>>>>
>>>>>>>>>> I am using the locale action at before any
>>>>>>>>>>
>>>> "map:match". I am
>>>>
>>>>>>>>>> passing the
>>>>>>>>>> locale as parameter but not using it in the XSL
>>>>>>>>>>
>>>> stylesheets.
>>>>
>>>>>>>>>> exemple:
>>>>>>>>>> <map:act type = "locale">
>>>>>>>>>> <map:match pattern = "index.html">
>>>>>>>>>> <map:generate src = "index.xml"/>
>>>>>>>>>> <map:transform src = "index.xsl"/>
>>>>>>>>>> <map:transform type = "i18n">
>>>>>>>>>> <map:parameter name = "locale" value =
>>>>>>>>>>
>>>> "{../locale}"/>
>>>>
>>>>>>>>>> </map:transform>
>>>>>>>>>> <map:serialize type = "xhtml"/>
>>>>>>>>>> </map:match>
>>>>>>>>>> </map:act>
>>>>>>>>>>
>>>>>>>>>> In the XSL stylesheet i transform the keys as :
>>>>>>>>>> <i18n:text>exemple.author.name</i18n:text>
>>>>>>>>>>
>>>>>>>>>> In the xslt transformer configuration I specified the
>>>>>>>>>>
>>>>>> parameters
>>>>>>
>>>>>>>>>> <use-request-parameters>true</use-request-parameters>
>>>>>>>>>>
>>>>>>>>> This is off topic, but I strongly recommend to
>>>>>>>>>
>> set this to
>>
>>>>>>>> FALSE, and
>>>>>>>>
>>>>>>>>> declare all your used parameters with
>>>>>>>>>
>>>>>> map:parameters...When crawlers
>>>>>>
>>>>>>>>> come by, they tend to have arbitrary parameters in the
>>>>>>>>>
>>>>>> url, implying
>>>>>>
>>>>>>>>> with your configuration 2 things:
>>>>>>>>>
>>>>>>>>> 1) Since all request parameters are taken in the cache
>>>>>>>>>
>>>>>> key (because
>>>>>>
>>>>>>>>> <use-request-parameters>true</use-request-parameters>),
>>>>>>>>>
>>>>>> then when a
>>>>>>
>>>>>>>>> request with arbitrary request parameter will
>>>>>>>>>
>> never match a
>>
>>>>>>>> cachekey,
>>>>>>>>
>>>>>>>>> having to generate your pipeline again
>>>>>>>>> 2) Your cache gets stuffed up with nonsense cachekeys
>>>>>>>>>
>>>>>> with arbitrary
>>>>>>
>>>>>>>>> values because of crawlers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The localeAction for cocoon 2.x is an action which
>>>>>>>>>>
>>>>>>>> injects the locale
>>>>>>>>
>>>>>>>>>> parameters from the session, the request or the
>>>>>>>>>> cookie(according to the
>>>>>>>>>> action configuration) if I'm right...
>>>>>>>>>>
>>>>>>>>>> The locale selection is managed through some
>>>>>>>>>>
>>>> javascript and
>>>>
>>>>>>>>>> everything is
>>>>>>>>>> working well when I'm not using a pipeline
>>>>>>>>>>
>> which type is
>>
>>>>>>>> "caching".
>>>>>>>>
>>>>>>>>>> I am not sure I'm doing anything the wrong way.
>>>>>>>>>>
>>>> Thanks for
>>>>
>>>>>>>>>> your response.
>>>>>>>>>>
>>>>>>>>> Can you do something for me? Clear your entire
>>>>>>>>>
>> cache, use
>>
>>>> <use-request-parameters>false</use-request-parameters>, and do
>>>>
>>>>>>>>> 1) request with certain locale ---> generate the status
>>>>>>>>> (StatusGenerator, you know to find it?) and look in the
>>>>>>>>>
>>>>>>>> EHDefaultStore
>>>>>>>>
>>>>>>>>> part at the created cache key.
>>>>>>>>>
>>>>>>>>> 2) Do request with different locale --> look again at
>>>>>>>>>
>>>>>> created cache
>>>>>>
>>>>>>>>> key. Did it override the previous one, or do
>>>>>>>>>
>> you now have a
>>
>>>>>>>> new one??
>>>>>>>>
>>>>>>>>> This should give you a clue about what is
>>>>>>>>>
>> missing in the
>>
>>>>>>>> cachekey. That
>>>>>>>>
>>>>>>>>> of course does not solve the problem, but can help you
>>>>>>>>>
>>>>>> debug this
>>>>>>
>>>>>>>>> problem (I am also not familiar with map:act
>>>>>>>>>
>>>>>> type="locale", so sorry
>>>>>>
>>>>>>>>> for not having direct answer).
>>>>>>>>>
>>>>>>>>> Ard
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Anybody there!
>>>>>>>>>> -----Original Message-----
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>>
>>>>>>>>>>>> We are writing a dynamic website with cocoon
>>>>>>>>>>>>
>>>>>> and with are
>>>>>>
>>>>>>>>>>>> confronted
>>>>>>>>>>>> to some problems.
>>>>>>>>>>>> We would like all the pages to be cached at
>>>>>>>>>>>>
>>>> startup for
>>>>
>>>>>>>>>> all possible
>>>>>>>>>>
>>>>>>>>>>>> specified languages. When the user change
>>>>>>>>>>>>
>>>> the locale, it
>>>>
>>>>>>>>>> should be
>>>>>>>>>>
>>>>>>>>>>>> reflected in all the application's pages.
>>>>>>>>>>>>
>>>>>>>>>>> Hmmm, you are caching every possible page at
>>>>>>>>>>>
>>>> startup?? With
>>>>
>>>>>>>>>> a crawler
>>>>>>>>>>
>>>>>>>>>>> or something? Or you mean only the
>>>>>>>>>>>
>> homepages? Or all?
>>
>>>>>>>> How do you do
>>>>>>>>
>>>>>>>>>>> all? And what if content changes? Do you have
>>>>>>>>>>>
>>>> to re-cache
>>>>
>>>>>>>>>> everything?
>>>>>>>>>>
>>>>>>>>>>> It looks like you are working like the
>>>>>>>>>>>
>> "forrest" guys.
>>
>>>>>>>>>> Cocoon has many
>>>>>>>>>>
>>>>>>>>>>> smart caching mechanism, like eventAware that
>>>>>>>>>>>
>>>> make running
>>>>
>>>>>>>>>> live without
>>>>>>>>>>
>>>>>>>>>>> warming up the caches is very well possbile
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> However the cache doesn't seem to be
>>>>>>>>>>>>
>>>> updated when the
>>>>
>>>>>>>>>>>> locale change.
>>>>>>>>>>>> The same page is often returned and sometimes a
>>>>>>>>>>>>
>>>>>> page with the
>>>>>>
>>>>>>>>>>>> previous
>>>>>>>>>>>> language settings.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Were are using Cocoon 2.1.9 and the
>>>>>>>>>>>>
>> localeAction with
>>
>>>>>>>> 3 languages
>>>>>>>>
>>>>>>>>>>>> (Spanish, English and trench). We were
>>>>>>>>>>>>
>> looking at the
>>
>>>>>>>>>>>> CacheEventAction
>>>>>>>>>>>> but it doesn't seem to be the way to go.
>>>>>>>>>>>>
>>>>>>>>>>> I am not aware of waht the localeAction
>>>>>>>>>>>
>> does. But I can
>>
>>>>>>>>>> imagine it is
>>>>>>>>>>
>>>>>>>>>>> at the end of your pipeline, right? And the
>>>>>>>>>>>
>>>>>>>> localeAction does not
>>>>>>>>
>>>>>>>>>>> implement CacheableProcessingComponent
>>>>>>>>>>>
>> interface. So,
>>
>>>>>>>> now, I have
>>>>>>>>
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>>>> quess what your problem is, but I have a clue:
>>>>>>>>>>>
>>>>>>>>>>> You do some generation part, then some xsl
>>>>>>>>>>>
>> transforms,
>>
>>>>>>>> and then a
>>>>>>>>
>>>>>>>>>>> localeAction..(hope i got it right)
>>>>>>>>>>>
>>>>>>>>>>> And probably, the generation part and the
>>>>>>>>>>>
>> xsl part is
>>
>>>>>>>>>> locale dependent.
>>>>>>>>>>
>>>>>>>>>>> But, you dont use the locale in there (as a
>>>>>>>>>>>
>>>>>> parameter). So, this
>>>>>>
>>>>>>>>>>> implies, your cache is built up until the first not
>>>>>>>>>>>
>>>>>> cacheable
>>>>>>
>>>>>>>>>>> component...(I suppose, but am not sure, and
>>>>>>>>>>>
>>>> have to sort
>>>>
>>>>>>>>>> it out if it
>>>>>>>>>>
>>>>>>>>>>> remains a problem, that this also holds for
>>>>>>>>>>>
>>>> map:actions and
>>>>
>>>>>>>>>>> map:selectors and stuff)
>>>>>>>>>>>
>>>>>>>>>>> Anyway, so your cache is build with a
>>>>>>>>>>>
>> generation part
>>
>>>>>>>> and some xsl
>>>>>>>>
>>>>>>>>>>> transformer, where the locale is not in it.
>>>>>>>>>>>
>>>> Now, changing
>>>>
>>>>>>>>>> your locale
>>>>>>>>>>
>>>>>>>>>>> will return the very same cache...solution:
>>>>>>>>>>>
>> do the xsl
>>
>>>>>>>>>> transformation
>>>>>>>>>>
>>>>>>>>>>> with an extra map:parameter, with
>>>>>>>>>>>
>> name="foo" and value
>>
>>>>>>>> equal to the
>>>>>>>>
>>>>>>>>>>> locale. You dont have to use this parameter in
>>>>>>>>>>>
>>>> your xsl. It
>>>>
>>>>>>>>>> only makes
>>>>>>>>>>
>>>>>>>>>>> sure, your cache key contains the locale (look in
>>>>>>>>>>>
>>>>>>>>>> StatusGenerator for
>>>>>>>>>>
>>>>>>>>>>> generated keys: probably, you dont see the
>>>>>>>>>>>
>> locale in it)
>>
>>>>>>>>>>> Hope this helps you out,
>>>>>>>>>>>
>>>>>>>>>>> Regards Ard
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> If someone could help, it would be great. We
>>>>>>>>>>>>
>>>>>> are kind of
>>>>>>
>>>>>>>>>>>> stuck with
>>>>>>>>>>>> Cocoon as it is considered as a show stopper for
>>>>>>>>>>>>
>>>>>> the project.
>>>>>>
>>>>>>>>>>>> Thanks in advance
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>> ---------------------------------------------------------------------
>>
>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>>
>>>> users-unsubscribe@cocoon.apache.org
>>>>
>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>
>>>> users-help@cocoon.apache.org
>>>>
>>>>>>>>>>
>>>>>>>>>
>> ---------------------------------------------------------------------
>>
>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>
>> users-unsubscribe@cocoon.apache.org
>>
>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>
>>>> users-help@cocoon.apache.org
>>>>
>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>
>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>
>> users-unsubscribe@cocoon.apache.org
>>
>>>>>>>> For additional commands, e-mail:
>>>>>>>>
>> users-help@cocoon.apache.org
>>
>>>>>>>>
>>>>>>>
>> ---------------------------------------------------------------------
>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>>>>>> For additional commands, e-mail:
>>>>>>>
>> users-help@cocoon.apache.org
>>
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>>>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>
>>>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>>>
>>>>>
>>>
>> ---------------------------------------------------------------------
>>
>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Localization and caching SOLVED
Posted by Ralph Goers <Ra...@dslextreme.com>.
Yves Zoundi wrote:
> Thanks again Ard and Bertrand.!
>
> Clearing the cache was the solution. Cocoon 2.1.9 does seem to be
> stable enough. I am having problems with dynamic errors when doing
> some xsl transformations. It doesn`t happen all the time but I can not
> put that into production. Hopefully it is a problem I can solve by
> mysef. I am using saxon8 as default xsl processor because it is
> faster. I will try downgrading to saxon 6.5.5 and use cocoon 2.1.8 to
> see if there are any changes.
>
> Thanks again.
>
You may find that the latest versions of XSLTC are faster.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org