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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
