avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [Interceptors] Definition and basic use cases
Date Wed, 04 Sep 2002 22:26:24 GMT


Igor Fedorenko wrote:
> 
> 
> 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?

At The Moment

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

>>> 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 :-)

Hahaha, you are right! :-D

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Mime
View raw message