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