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 14:50:28 GMT

Igor Fedorenko wrote:
> Nicola Ken Barozzi wrote:
>> Peter Donald wrote:
>>> Yep. It is a pattern fairly common to most "enterprise" 
>>> architectures. ie JBoss has it, as do most distributed component 
>>> impls (ie CORBA, DCOM etc).
>>> Some of them define "clientside" interceptors and some define 
>>> "server-side" interceptors while some architectures define both ;)
>>>> Now:
>>>>  1) where are these defined? Application-wide in the assembly?
>>> 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

>> Ah. But physically, they should be declared in the assebbly.xml file I 
>> guess. Or also in environment?
>>>>  2) how can these be defined? Must they be attatched to a specific
>>>> Service compulsory or can they go also with any service invocation?
>>> both ;)
>>>>  3) Interceptors are Components as well; they need to be managed as
>>>> other Components, because they will most probably need a Context 
>>>> because
>>>> they are stateless. How do I define them in the assembly? Is there a
>>>> creation order problem? Dependencies?
>>> Yep - Igor is already aware of this I believe ;)
>> Igor, any hints?
> You've asked for it, so get prepared for a very long and boring 
> explanation :-)


> I 100% agree that interceptors must be full-blown blocks (btw, I believe 
> the same applies to listeners as well) so I'll talk about creation order 
> and dependencies.

BTW, please forgive me if it sounds *%&/$£, but Merlin has the concept 
that all components are components are components, and describes the 
interrelations between these easily.
Is it only Merlin?
DOn't think so, but it means that the concept is already been tried, 
because it seems valid.

I will say Component instead of block here, as per the new terminology.

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

> 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 

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


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

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>

View raw message