avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Block context as shared source of block related information
Date Sun, 27 Oct 2002 08:08:37 GMT

I have been thinking through this and I can't quite decide what my opinion is 

By doing it the way that you describe you are essentially defining the 
applications environment by parts of the application. ie So the 
SecurityManager is just a Block as is the TransactionManager and so forth. 

Whereas currently the "parent" container (in our case the Application) defines 
the "environment" (ie ClassLoader, Thread names, policy, loggers etc). 
Personally I tend to favour this approach but I can see the advantage of 
allowing the "environment" to be part of the application rather than part of 
the Container.

What I would really like to see is an experiment to see which way works 
better. So maybe it would be good to just see it in code and then we can 
decide whether it is the right way to do things?

The difficult part will be that being a ContextContributor essentially adds a 
new layer of dependencies. For example, assume a SecurityInterceptor (SI) 
requires a SecurityManager (SM). The SM can not depend on any block 
transitively (sp?) that uses the SI as part of it's interceptor chain. 
Actually coding this up is going to be fairly painful. 

I dunno. Maybe we just see how it looks in code?

On Thu, 24 Oct 2002 01:23, Igor Fedorenko wrote:
> Hi,
> Interceptors and other stuff I am working on right now need extensible
> way to associate block with context information. For example, security
> infrastructure needs block's "security info", management needs block's
> "mx info" and so on. This has been already discussed (see
> "[Interceptors] Definition and basic use cases" thread) but I did not
> have time to implement it. As I finally have to do it I want to
> reiterate the idea to get some feedback from phoenix developers.
> Scope of context data.
> Application: same key/value pairs for all blocks. Example would be
> application home directory and name.
> Block: key/value pairs are specific to a particular block instance.
> Examples: block metadata, mxinfo, security info and so on.
> Invocation: different key/value pairs for each invocation. Examples are
> thread's transaction and security contexts.
> Context data layout.
> Application will have single application context instance (not sure if
> it is the same as ApplicationContext). For each block there is going to
> be one block context object with application context as a parent. To
> avoid confusion all application and block specific keys must be unique.
> Invocation context will be created by BlockInvocationHandler for each
> invocation and will keep a reference to block's context. Invocation
> context will be passed as parameter to Interceptor.invoke call (see bug
> 12405) and will be available as thread local to the blocks.
> Population block context with data.
> Application and block contexts will be populated by ContextContributors
> defined as
>      public interface ContextContributor
>      {
>          void contribute(ContextImpl context);
>      }
> ContextImpl is a subclass of DefaultContext that enforces key uniqueness.
> In assembly.xml context contributor will be specified with the following
> tags
>      <!ELEMENT context-contributor EMPTY>
>      <!ATTLIST context-contributor
>                class CDATA               #REQUIRED
>                scope (application|block) #REQUIRED>
> Invocation context will be populated by interceptors.


Peter Donald
|  I thought there was a knob on the TV to turn up the intelligence.  |
|      There's a knob called "brightness", but it doesn't work.       |

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