Jason van Zyl wrote:
>On 10/3/01 5:54 AM, "Santiago Gala" <[EMAIL PROTECTED]> wrote:
>
>>Jason van Zyl wrote:
>>
>>>On 10/2/01 1:21 PM, "Santiago Gala" <[EMAIL PROTECTED]> wrote:
>>>
>>>>I found the bug in the new patch for TurbineResourceService.
>>>>
>>>>The problem is when we use TurbineResourceService.getResources(prefix).
>>>>The variables that were defined in the root ResourceService
>>>>configuration are not carried onto the prefixed ResourceService, and so
>>>>interpolation fails.
>>>>
>>>I don't understand this. What is a prefixed resource service?
>>>
>>getResources(String prefix) returns a TurbineResourceService which
>>contains the items in the Configuration that start with the given
>>prefix. For instance, we use
>>
>>TurbineServices.getInstance().getResources("Registry"),
>>
>>which translates (in TurbineServices code) into
>>
>>TurbineResources.getResources("services." + "Registry"),
>>
>>which returns a new instance of TurbineResourceService, populated with
>>those resources like
>>
>>services.Registry.classname = ...
>>services.Registry.base.dir = ...
>>
>>starting with a prefix. This is achieved using Configuration.subset(prefix)
>>
>
>Got it :-) I will take a look at it today.
>
>
>>>
>>>I will help you today if I can get an understanding of what's failing.
>>>
>>>
>>>>It worked in the previous Jetspeed implementation due to the variable
>>>>cache, which was initialized inside the VariableResourceService
>>>>initialization, thus copying the webapp-related variables for each son.
>>>>
>>>Each child? I'm lost? Is this a jetspeed thing?
>>>
>>No. I mean each TurbineResourceService created with a given prefix (like
>>"registry", ...) It is a turbine feature.
>>
>>The problem is that this mechanism interferres with the variable
>>interpolation, because the new instance does not contain the special
>>variables inserted from the Turbine servlet init method.
>>
>>>
>>>>This is not done in the TurbineResourceService, where the variables are
>>>>inserted in the Resource Configuration from Turbine.init as a servlet,
>>>>only once and for the root TurbineResourceService.
>>>>
>>>>I have not attached a patch, since I have no clear idea of what is the
>>>>better way to solve it:
>>>>
>>>>- Re-create the caching of variables in TurbineResourceService, at least
>>>>for the variables arising from non-properties (webappRoot,...)
>>>>- Putting a reference to the "parent" TurbineResourceService into each
>>>>son (null for top one). Interpolation would be done recursively, first
>>>>in the "son" context, then up until either a response is found or a null
>>>>parent is found.
>>>>- Interpolating always in the context of the root
>>>>TurbineResourceService, by requesting it from inside the interpolation
>>>>code. It is something like changing *configuration.get(variable)* by
>>>>*TurbineServices.getinstance().getResources().getString( variable )* in
>>>>
In fact TurbineResources.getService().getString( variable ). I have
checked this patch and it works.
This is the patch. Just ignore the System.err.println(), they are for
debugging.
cvs server: Diffing src/java/org/apache/turbine/services/resources
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 -c -r1.4 TurbineResourceService.java
***
src/java/org/apache/turbine/services/resources/TurbineResourceService.java
2001/09/25 02:18:171.4
---
src/java/org/apache/turbine/services/resources/TurbineResourceService.java
2001/10/03 14:36:35 ***************
*** 223,233 ****
--- 223,238 ----
protected String interpolate(String base)
{
+ System.err.print( "Resources: Interpolating " );
+ System.err.println( base );
if (base == null)
{
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,248 ****
{
result.append(base.substring(prec+END_TOKEN.length(),begin));
variable = base.substring(begin+START_TOKEN.length(),end);
! if (configuration.get(variable)!=null)
{
! result.append(configuration.get(variable));
}
prec=end;
}
--- 245,255 ----
{
result.append(base.substring(prec+END_TOKEN.length(),begin));
variable = base.substring(begin+START_TOKEN.length(),end);
! System.err.print("Variable " + variable + " = " );
! System.err.println( top.getString(variable) );
! if (top.getString(variable)!=null)
{
! result.append(top.getString(variable));
}
prec=end;
}
>>>>
>>>>the interpolation code, possibly using a rootResources local var to
>>>>store the result of the constant calls.
>>>>
>>>>What do you think?
>>>>
>>>I don't know yet :-)
>>>
>>>
>>>>I think the third possibility is the simplest, as the first one is
>>>>tricky WRT dynamic resources, and the second is slow and complex. The
>>>>third one implies that all variables will be interpolated in the same
>>>>way by all TurbineResourceService instances, which looks like a "nice"
>>>>behaviour.
>>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>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]
