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
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.
- 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.
www.thinkdynamics.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
