Giacomo Pati wrote: >>> 1. IMO cocoon components should either use Settings.getRunningMode() to >>> get the current running mode or have the mode injected. Allowing >>> components to determine the running mode using any algorithm (even the >>> easiest one) leads to inconsistencies. > > I do absolutely agree with you. Exactly.
> >>> 2. Some components (like CocoonOverridePropertyConfigurer, which has >>> already been fixed) use the Settings object but happily fallback to >>> default mode when settings object is not available. The result of such >>> situation is that a bean that has been incorrectly dependence injected >>> uses other running mode than you might think. Beans using running mode. >>> should simply throw if they cannot determine one. > > As Carsten pointed out in a recent mail, we do not have the "original > working code" yet in the repo (dunno where it has been gone, nor which > ever class he had in mind as "original working code"). Maybe we should > just restore it and see whether that fix our problems Yes, let's please restore the old code in the settings element parser; I think that's all we need. > >>> I am probably picky about this but hey - you're the ones I've learnt my >>> values from :) > Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
