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" <[EMAIL PROTECTED]>
To: <[email protected]>
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:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
