portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject RE: Troubles testing Turbine 2.2 b2 for l10n
Date Mon, 19 Nov 2001 16:21:47 GMT
En dom, 2001-11-18 a 18:45, Ignacio J. Ortega escribió:
> I think i have more or less a explanation of the problem..
> When the resource service is asked to give a resources subset, the
> "System" resources (applicationRoot, webappRoot and others but basically
> this 2 ) are hidden and the interpolate method get null when trying to
> use the configuration passed as source for that variables.. no idea
> about possible fixes .. in the way it's done right now the only
> workaroud i see is to not use the same subsetted configuration when
> trying to find the interpolation variable.., maybe to store this vars
> inside the object (  VariableResources flavour ) in another HAshTable,
> or pass around the complete config.. 

Yes, the problem is this one. I posted it to the turbine-list (or maybe
it was to Jason only) in September.

I have two^H^H^Hthree possible solutions:

1- The simple one, only works for turbine-2: apply this patch:

RCS file:
retrieving revision 1.4
diff -u -r1.4 TurbineResourceService.java
src/java/org/apache/turbine/services/resources/TurbineResourceService.java	2001/09/25 02:18:17
src/java/org/apache/turbine/services/resources/TurbineResourceService.java	2001/11/19 15:54:01
@@ -228,6 +228,9 @@
             return null;
+        //Get the full ResourceService (we could be in a subset
+        ResourceService top = TurbineResources.getService();
         int begin = -1;
         int end = -1;
         int prec = 0-END_TOKEN.length();
@@ -240,9 +243,9 @@
             variable = base.substring(begin+START_TOKEN.length(),end);
-            if (configuration.get(variable)!=null) 
+            if (top.getString(variable)!=null) 
-                result.append(configuration.get(variable));
+                result.append(top.getString(variable));

This patch is good for Turbine-2. It basically says: "interpolate always
in the *root* resources". It is not good for commons/turbine-3 because
it introduces a turbine dependency.

2- Make that a ExtendedProperties (turbine-3/commons) has an instance
var called, say, parent. When subset is used, the parent is stored
there. Then, interpolate would use something like (it is really more
complex, keep on reading):

if( null != parent ) 
} else {
The semantics could be made parent-first (i.e.the parent chain is looked
first, until a result is found *or* parent is null), or child-first
(i.e., if the variable gets a value in the children, this value is
returned, else parent is tried until parent is null).

The results can be *very* different. For instance ${rooDir} would pick
the high level one in parent-first, but it would pick
services.network.rootDir=xxx in child first, if we are asking for a
"services.network" subset.

3- Remove the "subset()" method, i.e. don't offer this feature to the
users of the class, and keep interpolation. This could be a reasonable
possibility. We could stop using this feature, and rewrite the offending

The first patch is a reasonable workaround for turbine-2, but it is not
acceptable for turbine-3/commons. It is the one I sent Jason.

I hope I have summarized correctly the issues here.

I could implement and test the second alternative for turbine-3/commons,
but nobody really asked. I am interested that this class work, we are
using it a lot.

To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

View raw message