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
>>> 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]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
