You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Igor Fedorenko <if...@thinkdynamics.com> on 2002/10/23 17:23:05 UTC
Block context as shared source of block related information
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Block context as shared source of block related information
Posted by Peter Donald <pe...@apache.org>.
On Tue, 29 Oct 2002 03:09, Igor Fedorenko wrote:
> 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.
I like that - but that just becomes a generic hierarchial container. So each
container has components and interceptors. Interceptors can use services of
parent container while components can use services of their peers.
I love the idea and think it is great. It is just a lot of work to get right
;)
> > 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).
Yep. But they have hierarchial containers. ie Interceptors don't depend on
EJBs (equivelent to our blocks).
> > 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?
Whatever you have got would be interesting to look at.
--
Cheers,
Peter Donald
-----------------------------------------------
"Only two things are infinite, the universe and
human stupidity, and I'm not sure about the
former." -Albert Einstein
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Block context as shared source of block related information
Posted by Igor Fedorenko <if...@thinkdynamics.com>.
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:
>
>>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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Block context as shared source of block related information
Posted by Peter Donald <pe...@apache.org>.
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.
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.
--
Cheers,
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>