On 19.08.2007 18:12 Uhr, Grzegorz Kossakowski wrote:
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?
Yes.
If so performance loss would at the most two times slower.
What does this mean? This sentence makes no sense to me ;)
If you take into account components that actually do something the
performance loss could be less noticeable I think.
It's about complexity calculations [1]. Your approach is of O(m*n) with
m = number of SAX events and n = number of components. The environment
change has to be executed m*n times. With my approach it was only
O(1*n). Ignore the number of components it's O(m) vs. O(1) - and number
of SAX events can be huge. That's why it is not lightweight.
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.
Auto-proxying only starts in chapter 7.9 [2] :)
You can probably just move the code of ScopeChangerProxy straight to a
subclass of AbstractAdvisorAutoProxyCreator (which would be coupled to
Spring as a BeanPostProcessor is, actually it is a BeanPostProcessor as
well but does the proxying for you) or to a MethodInterceptor.
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 see. The best lightweight approach is useless if it does not meet the
requirements ;) Let me thnk about it ...
Joerg
[1] http://en.wikipedia.org/wiki/Computational_complexity_theory
[2]
http://static.springframework.org/spring/docs/2.0.x/reference/aop-api.html#aop-autoproxy
