Joerg Heinicke pisze:
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!
Correct me if I'm wrong but I thought that every pipeline component handles (even if it's simple
forwarding) every single SAX event, right? If so performance loss would at the most two times
slower. If you take into account components that actually do something the performance loss could be
less noticeable I think.
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.
I'm not Spring specialist, BeanPostProcessor was the first thing I found in docs (chapter 3) that
fitted my needs. I'll adjust my code tomorrow.
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.
Ok, so component (let it be transformer) has wrapped OM puts local variable on wrapper only. Now
imagine that transformer is BeanFactoryAware that uses some other component (let it be a Foo
component) to transform some elements. Foo components depends on Bar component, that in turn depends
on Object Model.
What original transformer writer could expect is that it's current state of it's Object Model
(wrapper) is visible to the Bar component as it is derived from the transformer. As you guessed it,
only unwrapped Object Model will be visible to the Bar component.
I hope that you understand now why scope and it's changing is needed.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection
***
*** incessantly so I'll not be able to respond to e-mails
***
*** regularly and my work will be somehow irregular.
***
*** I'm already trying to switch ISP but it will take handful amount of time.
***
