On 19.08.2007 10:03 Uhr, Grzegorz Kossakowski wrote:
> Same goes for all other SAX events. It's actually one extra get and two
> puts calls on Map. Rather lightweight, yes?
But as you say it has to happen for EACH SAX event. I don't think it's
lightweight. It happens hundreds times even for simple HTML pages - per
component!
> I want to create dynamic proxies around pipeline components. Actual
> wrapping would be performed by class implementing BeanPostProcessor
> interface.
Why do you go this low-level approach and instead of just implementing a
MethodInterceptor applied with Spring's AOP. That makes it independent
from Spring itself since the interceptor can be applied differently later.
> However, going with this path makes whole pipeline scope completely
> *orthogonal* to the pipeline and its components' code.
I wonder if that's a requirement at all. IMO a properly scoped OM *is*
part of the component setup. So I would not even care if the
corresponding code has to be touched.
Anyway, I can't see where the simple wrapper approach fails. We'll get
kind of a hierarchical OM similar to Spring's hierarchical application
contexts. Creating the wrapped OM can happen in the same AOP/
BeanPostProcessor way, but it happens only on setup time and once, not
for each SAX event by intercepting the setObjectModel() method:
on setObjectModel(parentOM) on component xy
do xy.setObjectModel(new ObjectModelWrapper(parentOM))
The ObjectModelWrapper holds a map of local vars and delegates to the
parent OM if it can not find a value in its local vars.
Joerg
|