On Sun, May 11, 2008 at 6:59 PM, Joerg Heinicke <[EMAIL PROTECTED]> wrote: > On 09.05.2008 09:41, Peter Hunsberger wrote: > > > > > > I haven't looked at the code here, but couldn't you just introduce a > > second getOutputStream( int bufferSize ) method where the current > > interface method continues with the current default logic if it is > > used? > > > > getOutputStream() actually already takes an int parameter, the flush buffer > size.
Yeah, I saw that... > Whether to add another getOutputStream() method or modify the existing > one there is not really a difference IMO. Environment is a kind of internal > interface (or SPI how it used to be called lately, isn't it?). This means > there should be only very few implementations besides the one we provide if > at all (Forrest, Lenya, CLI environment?). And in Cocoon we would change all > usages of the single-parameterized method to the one with 2 parameters. So > whoever provides such an Environment implementation has to adapt his > implementation in a meaningful way anyway (empty implementation returning > null, throwing NotSupportedException, whatever would not work). So it's the > same effort for them whether to add a new method or changing existing one on > the interface. I don't see that, you can continue the existing behaviour for those who don't change? > IMO the decision should be made purely from a design perspective. Should a > configuration parameter passed around as method parameter though it is > static through the whole lifecycle of the Environment instance? In a perfect > world I'd say no :) That makes sense. Guess the question in that case is; are the are any use cases where people could use such a parameter as not static? > Which leaves the question how to inject the parameter. > One place is on instantiation (e.g. CocoonServlet.getEnvironment(..) in 2.1, > RequestProcessor.getEnvironment(..) in 2.2) which leaves us with the web.xml > init parameter (or analogical alternatives for other environments) as > described. > > Another option I found is to setup the environment (i.e. injecting the > parameter) while setting up the pipeline. AbstractProcessingPipeline is the > place where we have access to the current flush buffer size parameter and > call getOutputStream(..) on the environment. It has a method > setupPipeline(Environment). Why not injecting the parameter(s) here? Due to > its lifecycle changing the property of the environment should not cause any > problem since it's a one-time usage object, no threading problems or > something like that. > Seems reasonable. [snip/] -- Peter Hunsberger
