avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <ifedore...@thinkdynamics.com>
Subject Re: [Interceptors] Definition and basic use cases
Date Wed, 04 Sep 2002 22:51:23 GMT

Nicola Ken Barozzi wrote:
>>>> Blocks must not know anything about their interceptors, so blocks do 
>>>> not depend on interceptors. Interceptors on other hand most likely 
>>>> depend on blocks they intercept. For example, jaas interceptor I am 
>>>> working on needs access to block metadata.
>>> Yes, I agree.
>>> But... (see next example)
>>>> I am not sure if interceptors need access to block state though.
>>> Block state?
>>> You mean the Context?
>> No, I meant hard data stored inside component instance.
> Ok, then the answer is no.

>>> Most probably yes. Think of an authentication interceptor; it must be 
>>> able to see the info on the request, which also the block needs to see.
>>> The fact is that both the interceptor and the block need to have 
>>> specified the keys they will use.
>>> Does this tie the two together somewhat, also the other way around?
>> I agree, that Context as a common place for all sorts of context 
>> parameters sounds cool, but there is no way to add something into a 
>> Context. 
> Ok.
>> We'll need to change Context interface to support interceptors that 
>> need to store their own context data. It looks too complicated to me 
>> -- there is application wide context, per-block contexts (and 
>> interceptors need access context of blocks thet intercept) and 
>> per-call contexts, so we need a way to manage this; we also a way to 
>> prevent name conflicts. If you guys are happy with this amout of work 
>> that's fine with me but I need a short term solution as well.
>> Also keep in mind that there are other sources of context information 
>> already -- AccessController.getContext() and 
>> TransactionManager.getTransaction() for example -- so we cannot have 
>> single repository of all context information anyways.
> Hmmm...
> So, what do you practically propose?

Well, if I were avalon/phoenix developer I would adopt read/write 
Context as a long term solution and accept my "separate interceptor 
instance for each block" approach for the time being. Nice thing about 
second part of this proposal is that I am willing to develop it in a 
very timely manner. However, if you are not interested in it, well, too 
bad, I'll create my local version of phoenix and will maintain it until 
implementation of the long term solution.

Igor Fedorenko
Think smart. Think automated. Think Dynamics.

To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>

View raw message