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 14:38:13 GMT

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.

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

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. I am not sure if interceptors need 
access to block state though.

There are two possible implementations of per-application and per-block 

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

- One shared interceptor instance serves all legitimate blocks. It is 
not clear how to track dependencies between interceptor and all blocks 
it intercepts. 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 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?

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