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:01:52 GMT

Nicola Ken Barozzi wrote:
> Igor Fedorenko wrote:
>>>> Possibly it could be per-application, per-component, per-service or 
>>>> even per "client".
>> Is there a concept of a client in phoenix at the moment? I'd like not 
>> to consider per-client interceptors, at least for now.
> +1 ATM
Excuse my ignorance, but what "ATM" stands for?

>> 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.

> 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. 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.

>> There are two possible implementations of per-application and 
>> per-block interceptors:
>> - Separate instance of an interceptor is created for each legitimate 
>> block. Interceptors are created at the same time block's proxy is 
>> created, i.e. after block has been fully initialized and started but 
>> before anyone knows about it. Dependency between the interceptor and 
>> the block can be made explicit during application assembly, so there 
>> is no problem here as well. Interceptor instance could keep block 
>> specific state if it needs to. For example, jaas interceptor keeps 
>> block's security setting so it does not needs to recreate them at each 
>> call. The only disadvantage of this implementation I can think about 
>> is lack of centralized management view at all instances of a "same" 
>> interceptor.
> IMHO interceptors need to be stateless, so no caching.
> All the settings need to be in the Context, both for the block and the 
> interceptor.
See above.

>> - One shared interceptor instance serves all legitimate blocks. It is 
>> not clear how to track dependencies between interceptor and all blocks 
>> it intercepts. 
> A list of blocks, a regexpr match, ...
>> We also need to change block's creation sequence to give the 
>> interceptor a chance to initialize its state for a block after the 
>> block has been initialized 
> As the case before, only that it's performed once per block.
>> and we need a way to associate this state with the block and pass it 
>> along with every invocation.
> Context.
>>>>>  4) Should the Context be the app-defined one? Shall the Context be
>>>>> created per invocation and used only privately by the interceptors?
>>>>> Shall it reside inside the app context via a defined key?
>>>> as in getBlockContext().getApplicationContext() ? Could do - Phoenix 
>>>> does not have the notiiiion of shared data storage area though and I 
>>>> guess that may be something we can consider after release.
>>> It is needed because the interceptors need a place where to put data 
>>> between invocations, since they are stateless.
>>> I guess that
>>>   contextualize(Context context){
>>>    Context interceptorcontext = context.get("avalon:appcontext");
>>>   }
>>> could do.
>> I am not sure what information whould interceptorcontext provide. I 
>> was thinking about
>>    contextualize(Context context){
>>       BlockInfo blockInfo = context.get(InterceptorContext.BLOCK_INFO);
>>    }
>> Is it something similar?
> Yes. You forgot the cast though.

So did you :-)

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