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:
Index:
src/java/org/apache/turbine/services/resources/TurbineResourceService.java
===================================================================
RCS file:
/home/cvs/jakarta-turbine-2/src/java/org/apache/turbine/services/resources/TurbineResourceService.java,v
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 1.4
+++
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
instance)
+ ResourceService top = TurbineResources.getService();
+
int begin = -1;
int end = -1;
int prec = 0-END_TOKEN.length();
@@ -240,9 +243,9 @@
{
result.append(base.substring(prec+END_TOKEN.length(),begin));
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));
}
prec=end;
}
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 )
{
parent.get(...)
} else {
this.get(...)
}
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
services.
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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
