Re: [RT] The Ominous Context

Stephen McConnell Mon, 14 Jul 2003 02:54:58 -0700

Nicola Ken Barozzi wrote:

Niclas Hedhman wrote, On 14/07/2003 9.42:

Stephen wrote:

I hate this subject because I keep changing my mind!

Isn't that a good thing?

:-))

<snip reason="agree" />

I still don't get the example you write, Stephen: "Context represents an import stage during which a container can gather non-component artifacts and apply them to a component before servicing occurs. A context entry could be something like a KeyStore which can be used by a component during the servicing stage (as an example)".

Could you please explain a bit more in detail?

Sure - as thing stand we have a phased lifecycle [deployment [instantiation], [logging],[contextualization],[servicing],[configuration],[parameterization], [create-extension,...],[initialization],[start]], and the corresponding decommissioning phases.

During deployment there are a number of points during which context information is exposed:

 1. during the contextualization phase
 2. during the create-extension[n] handling
 3. during the access-extension handling
 4. during the release-extension handling
 5. during the destroy-extension handling

The context gathering stage inside a container can occur as soon as you bring together the meta-info and meta-data. Your not concerned with dependencies or assembly semantics - your just concerned with mapping and/or constructing context entries. The more information you push into context entry dependency declarations (and corresponding context entry directive) the small your code gets because your basically telling the container to take care of the problem for you. In addition, you lifecycle extensions can get a lot smarter because they have more information available to them. This means more deduction in component implementation responsibility - a.k.a improved S.O.C.

Here is a more concrete example (cut-and-paste from the composition package). First of all the type information which is where the component is declaring if computation dependencies:

<type>
 <info>
   <name>component-a</name>
   <lifestyle>singleton</lifestyle>
 </info>
 <context>
   <entry key="urn:avalon:partition.name"/>
   <entry key="urn:avalon:classloader"/>
   <entry key="urn:avalon:home.dir"/>
   <entry key="urn:avalon:temp.dir"/>
   <entry key="urn:avalon:name" alias="name"/>
   <entry key="home" type="java.io.File"/>
   <entry key="time" type="java.util.Date" volatile="true"/>
 </context>
 <services>
   <service type="org.apache.avalon.composition.model.testa.A"/>
 </services>
</type>

If we look at the last context entry "time" - this is basically a statement by the component that it needs a time value. This could serving a secure time-stamp or whatever (you could add attributes under the entry to qualify the criteria). On the other side of the equation (moving from meta-info to meta-data) we see some directives that tell the container how to construct the Date value:

<container>

  <component name="test-a"
       class="org.apache.avalon.composition.model.testa.TestA">
    <context>
      <entry key="home">
        <constructor class="java.io.File">
          <param class="java.io.File">${urn:avalon:home.dir}</param>
          <param>xxx</param>
        </constructor>
      </entry>
      <entry key="time">
        <constructor class="java.util.Date"/>
      </entry>
    </context>
  </component>

</container>

This is the real cheap-and-nasty Date instance creation - simply instanting a new instance of java.util.Date. What is important to note is that this could be a full blown secure time-server provide the Date instance. The actual decision is presented under the container side of the system.

An important aspect here is the management of individual entries (context or service). The meta-data (directives) basically break down into a object model (which is where JMX management comes in). For any given entry (service or context) we can:

 1. differentiate between context and service (inside
    the container) - which means I still get the early
    harvesting of information that I want

 2. while abstracting this difference out from the
    component implementation and runtime viewpoints

Now I bet that made things really clear ;-)

Cheers, Steve.

TIA

...
From my perspective (being, or trying to be, mainly a component author) it is fairly irrelevant whether it is in the Contextualizable or Serviceable contract, as long as;
1. It is a single lookup.
2. If the container doesn't provide it by default, I can provide an
implementation.
And your suggestions above seems to fulfill this very well, the rest is
implementation details ;o).
I tend to agree.

Do the ones that *use* containers need to implement the Context and cannot use a Service instead? Because this is the main point IMHO.

As a delivery mechanism I don't need both interfaces. As a declaration mechanism (meta-data) I need both the notions of context and service (or in other terms - atomic objects verus assembled objects).

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]

Re: [RT] The Ominous Context

Reply via email to