J Aaron Farr wrote:
On Tue, 2003-07-08 at 17:40, Stephen McConnell wrote:
I would like to propose the following as a standard set of context entry name. These names deal with the context entry names that componets should use (i.e. I'm not thinking about container side context keys).
urn:avalon:partition.name -- the partition name in merlin and the application name in Phoenix urn:avalon:name -- the deployment scenario name (i.e. for a singleton this is the component name or block.name in Phoenix, for other lifestyles, the name may not be unique across component instances, but the name is unique within a single containment scope) urn:avalon:home.dir -- a directory that a container can gaurantee to make available across JVM sessions (unique per component that requests it) urn:avalon:temp.dir -- a directory that is made available to a component and will be destroy on JVM termination (unique per component that requests it) urn:avalon:classloader -- a classloader for the component (may not contain any containment classes)
This would cover almost everything. I'm not sure what the partition.name would be for Fortress though.
Merlin uses partition names to reflect the containment hieracy. The root container establishes the partition "/" a container with the name "reginald" aquires the path "/reginal" when deployed inside the root container - a component named "pecan" executing inside "reginal" can be consider to be on the path "/reginald/pecan".
I can imagine the same logic can be applied to Fortress when dealing with nested containment.
The only things not covered which Phoenix's BlockContext provide are:
getResourceAsStream(String) requestShutdown()
and I'm not certain these should be in the context anyway.
This feels like kernel/container extensions to me.
The component declares what it needs in meta. This encorages good SOC bacause the component implementation cannot do navigation or discovery - if it needs something it has to say what it needs and the container has to deal with the supply.And why is there no way to get a list of all context values from the Context interface? All we have is get(Object key).
Understood. However, currently there isn't a consistent way for containers to provide these dependencies.
Perhaps this would be a good spot for assembly/container events. For example, in the servlet spec, you have ServletContextListener. What about an AvalonContextListener? Listeners would have a chance to update or modify the Context before it's passed to any services, blocks, components, etc. There might be creation listeners or access listeners. For example, in addition to adding simple configuration values to the Context, you could map a JNDI InitialContext or ServletContext into the Avalon Context.
Just brainstorming at the moment.
Here's a couple of thought of my own on the subject.
* Current status ...
The current meta-data format for context entries in Merlin allows two modes of expression
(a) import context entries from container space and mapping
these to key in component space
(b) creation of new context entries based on the composition
of primitive valuesThe existing structure looks like:
<context>
<import key="my-classloader" name="urn:avalon:classloader"/>
<entry key="special-key" class="MySpecialClass">
<param>Hello World</param>
</entry>
<entry key="special-key" class="AnotherSpecialClass">
<param>MyDualArgConstructorClass<param>
<param>Hello World</param>
<param class="java.io.File">../lib</param>
</param>
</entry>
</context>It would be preferable to modify this such that the context element is restricted to <entry> tags and that the semantics of the entry are interpreted based on their content. For example, applying the same example as above we could imagine an equivalent directive:
<context>
<entry key="my-classloader>
<import key="urn:avalon:classloader"/>
</entry>
<entry key="special-key" class="MySpecialClass">
<param>Hello World</param>
</entry>
<entry key="special-key" class="AnotherSpecialClass">
<param>MyDualArgConstructorClass<param>
<param>Hello World</param>
<param class="java.io.File">../lib</param>
</param>
</entry>
</context>This approach makes is much similar to expand the model to include new semantics. The following example incorporates the declaration of an extension component that will acting in the role of context provider for a named entry.
<context>
<entry key="my-classloader>
<extension type="org.apache.wizard.SpellBook"/>
</entry>
</context>This addresses two concerns, firstly, the introduction of a more flexible approach to context provider association, and secondly, ensures that the association is explicit.
* Broader thoughts concerning extension declaration ...
With the recent introduction (at the test-case level) of support for the total separation of container versus component clasloaders there is anyway the requirement to declare within the meta-data an explicit introduction of an extension provider for a target component or components.
Consider a classic <component/> declaration:
<container name="root">
<component name="toto" class="MyComponent"/>
</container>This could be expanded to include explicit declaration of an extension provider as shown below:
<container name="root">
<component name="toto" class="MyComponent">
<extension class="AnExternalExtensionProvider"/>
</component>
</container>* On granting rights to extensions ....
Components acting as lifecycle stage handlers (classic extension),
appliance extension, context providers, etc. gain varying degrees
of access to information. Lifecycle extensions can override context
information, appliance extensions can navigate inside container
space. This requires (a) authentication of these resources (I'm
thinking JNLP style here), (b) control over execution rights,
and (c) some form of privilege management. On the other-hand, something like a context-provider-plugin can be (a) separated
from the system classloader (i.e. isolated), and (b) audited -
which makes this approach much more manageable. The same holds
true for the event listener approach expect that we are separating
the extension away from the actual component instance (which
reduces risk).
I think we need things like appliance linked extensions (the JMX automation is a really good example because a JMX extension really needs to get into the inside of the container. But I think that this style of extension should be subject to explicit control (i.e. putting something inside a block is insufficient) We need execute authorisation at a higher level such as the kernel.
* And a late night summary ...
1. We need something like the appliance-based extension
but it should be configured as part of the kernel
definition. Such extensions should be constrained
relative to: (a) their ability to navigate internally
(b) phase of execution (e.g. only activated during
composition, or assembly, or runtime only,
or some combination)
(c) scope of execution (probably linked to classic
java security polices)
(d) must be authenticatable 2. Pluggable extension components along the lines of
the existing lifecycle extensions can be considered
as part of the component solution - providing the
component can be absolute about an extension handler
selection. This not the case currently but will be
addressed with the incorporation of explicit and/or
conditional assembly directives. E.g. <component name="fred" type="Widget">
<assign key="best-friend">
<select component="bob">
</assign>
</coponent> Meaning that the component name "bob" gets locked in
as the service provider for a role called "best-friend"
for the component "fred". You can probably image a
bunch of variations on the select ranging from
specific feature references (as in the above example)
through to regular expressions statements. These
structures materialise as manageable objects - at
least a big part of the rationale related to the
composition package. 3. Lastly, listener style extensions are probably the
the best direction for general containment extension
assuming that it is restricted to interaction on
artefacts (context entries, configuration,
parameters), does not interact with components
or services, and finally - can be completely
isolated from the system classloader.Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
