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