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: Block context as shared source of block related information
Date Mon, 28 Oct 2002 16:09:14 GMT
Peter Donald wrote:
> Hi,
> 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.
Not necessary. We can introduce additional configuration layer between 
the container and the application which will define context 
contributors, interceptors and other optional container services. 
Applications will declare which additional services they depend on and 
deployers will make sure that all requirements are met. We can even have 
per-component (a.k.a block) containter configuration although I am not 
sure that it is necessary if we allow inter-sar communication.

> 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?
Take a look at JBoss. It has different container configuration for 
different types of EJBs and target deployment environment (deploying CMP 
beans into oracle is different from db2).

> 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?
Sure. What exactly do you want to see, part that supports context 
contributors in phoenix (this was surprisingly big change due to current 
DefaultApplication/BlockEntry implementation), usage of context 
contributors in some test app or both?

> On Thu, 24 Oct 2002 01:23, Igor Fedorenko wrote:
>>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
>>     <!ELEMENT context-contributor EMPTY>
>>     <!ATTLIST context-contributor
>>               class CDATA               #REQUIRED
>>               scope (application|block) #REQUIRED>
>>Invocation context will be populated by interceptors.

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