cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: Pipeline components and Object Model issues
Date Sun, 19 Aug 2007 22:57:49 GMT
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

Mime
View raw message