Return-Path: 
 <dev-return-70351-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 20701 invoked from network); 14 Jan 2005 16:15:59 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 14 Jan 2005 16:15:59 -0000
Received: (qmail 95420 invoked by uid 500); 14 Jan 2005 16:15:54 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 95333 invoked by uid 500); 14 Jan 2005 16:15:54 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 95306 invoked by uid 99); 14 Jan 2005 16:15:53 -0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: domain of ap-cocoon-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
Received: from main.gmane.org (HELO main.gmane.org) (80.91.229.2)
  by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 14 Jan 2005 08:15:53 -0800
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1CpU6s-0005XC-00
	for <dev@cocoon.apache.org>; Fri, 14 Jan 2005 17:15:48 +0100
Received: from srvgw12.rauser-ag.com ([217.146.133.165])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <dev@cocoon.apache.org>; Fri, 14 Jan 2005 17:15:37 +0100
Received: from joerg.heinicke by srvgw12.rauser-ag.com with local (Gmexim 0.1
 (Debian))
        id 1AlnuQ-0007hv-00
        for <dev@cocoon.apache.org>; Fri, 14 Jan 2005 17:15:37 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: dev@cocoon.apache.org
From: Joerg Heinicke <joerg.heinicke@gmx.de>
Subject: Re: i18n catalogues and caching
Date: Fri, 14 Jan 2005 16:15:31 +0000 (UTC)
Lines: 32
Message-ID: <loom.20050114T171144-699@post.gmane.org>
References: <loom.20050113T163041-261@post.gmane.org>
 <41E7EC42.8060003@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: main.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 217.146.133.165 (Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE;
 rv:1.7.5) Gecko/20041122 Firefox/1.0)
Sender: news <news@sea.gmane.org>
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

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