Block context as shared source of block related information

[Igor Fedorenko]

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.

--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com


--
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>