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)
>
>
>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
>>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]
