Interception StringBuffer not thread safe for multi-event executions


I think, there is architectual issue with string buffer for interceptors. Every event creates an own request buffer.
But every request buffer uses the same string buffer object located in request scope.

In case of an event is triggered within an event, this produces some trouble. This especially happens if a interceptor uses providers to get some instances from wirebox, cause then additional events are triggered.

Example: Interceptor A and B are listening on event Z. A puts content to request buffer. B is executed after, uses a provider, a new event is called, a new request buffer is created, this event was executed completely, request buffer is cleared, in this case the string buffer in request scope. The content of Interceptor A is gone.
Interceptor B puts some data to request buffer, this apprears on output.



Luis Majano
February 21, 2018, 5:22 PM

Interesting. However the ideas was to have a buffer not per request but per state. So once the execution of a state is done thenrwuesr buffer for the state would be out putted. Even if there were other vents in the mix. I will need to revise this. Since the buffer should be at the per state execution.

Matthias Richter
February 22, 2018, 9:13 AM

Maybe, there is an additional thing to care about this.
In installations with contentbox, in function cbhelper.event the output flag is set to true.
If an instance set his output to false and run an additional event, not using cbhelper to trigger an event, this output flag is furthermore set to false. In this case the output might not be outputted, but the buffer will be cleared.



Luis Majano


Matthias Richter




Fix versions