You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Farr, Aaron" <Aa...@am.sony.com> on 2003/07/08 22:19:52 UTC
Avalon Context Survey
Hello.
Wow. Even going on a short vacation around here leads to a dangerously
large inbox upon return. :) I'm still working through the avalon-meta
thread. Sounds very good so far. Any idea when it will be safe to play
with? I had a couple enhancements I wanted to add to the meta package in
respect to the Merlin deployment stage extensions.
In the meantime I've started on summarizing the current container supplied
context keys. I have Fortress done so far. I'll probably get to Merlin and
maybe Phoenix tomorrow:
http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonContextSurvey
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).
J. Aaron Farr
SONY ELECTRONICS
DDP-CIM
(724) 696-7653
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Avalon Context Survey
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> I would like to propose the following as a standard set of context entry
> name.
didn't we spend 3 weeks doing just that back in january or so? If
there's significant change between the compromise we reached then and
what you wrote then we're not ready for any kind of "standard".
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Avalon Context Survey
Posted by Stephen McConnell <mc...@apache.org>.
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.
>
>>>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).
>>>
>>>
>>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.
>>
>
>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 values
The 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:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Avalon Context Survey
Posted by J Aaron Farr <ja...@yahoo.com>.
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.
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.
>
> >
> >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).
> >
>
> 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.
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.
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Avalon Context Survey
Posted by Stephen McConnell <mc...@apache.org>.
Farr, Aaron wrote:
>Hello.
>
>Wow. Even going on a short vacation around here leads to a dangerously
>large inbox upon return. :) I'm still working through the avalon-meta
>thread. Sounds very good so far. Any idea when it will be safe to play
>with? I had a couple enhancements I wanted to add to the meta package in
>respect to the Merlin deployment stage extensions.
>
>In the meantime I've started on summarizing the current container supplied
>context keys. I have Fortress done so far. I'll probably get to Merlin and
>maybe Phoenix tomorrow:
>
>http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonContextSurvey
>
>
Merlin (current):
urn:avalon:partition String partition name
urn:avalon:name String component/scenerio name
urn:avalon:home File (directory) persistent directory
urn:avalon:work File (directory) temproty directory
urn:avalon:classloader ClassLoader component classloader
Phoenix:
app.name String application name
block.name String component name
app.home File (directory) persistent directory
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)
>
>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).
>
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.
Cheers, Steve.
>
>
>J. Aaron Farr
> SONY ELECTRONICS
> DDP-CIM
> (724) 696-7653
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Avalon Context Survey
Posted by Leo Simons <le...@apache.org>.
Farr, Aaron wrote:
> Wow. Even going on a short vacation around here leads to a dangerously
> large inbox upon return. :)
scary, innit? ;)
> In the meantime I've started on summarizing the current container supplied
> context keys.
search the archive for "Leo Sutic" and "context" and similar stuff. We
had a grande debate a few months back and I'm guessing everything pretty
much got docced and explained in the process.
> 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).
I'm not up to speed on the original design decision, but the CoP/IoC
idea sorta means that a component should know what is available from the
context and what is not, and that the container should not initialize it
when there's a problem (ie cascade ContextException on a bad get() back
to the container).
I don't think there's enough of a use case here to warratn a change.
Please attempt to change our minds ;)
Of course, if it were me, and I were to make the decision again now, I'd
just use the Map interface :D
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org