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: <mailto:avalon-phoenix-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@;jakarta.apache.org>
