avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: DTD compat -- red herring?
Date Thu, 22 Aug 2002 00:13:33 GMT


Paul Hammant wrote:

> Stephen,
>
>>>>> This is possible without including any reference or depedency on 
>>>>> Merlin providing we settle the.xinfo DTD. I would like at add 
>>>>> another couple of points:
>>>>>
>>>>> 5) utilities enabling component migration
>>>>>
>>>>> One of the problems I have had to deal with concerning existing
>>>>> components are references to things like BlockContext. Merlin can
>>>>> work around this through its context management system. A container
>>>>> indepedent solution called GenericBlockContext was added to the
>>>>> Phoneix CVS. This seemed the correct thing to do as opposed to
>>>>> creating a Phoenix depedency in the Merlin CVS.
>>>>>
>>>>> The original contribution is under the Phoenix CVS (Attic).
>>>>> org/apache/avalon/phoenix/tools/export/GenericBlockContext.
>>>>>
>>>>> Are there any objections/issues to bringing this class back into
>>>>> action? 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> As nobody has objected to this I'll go ahead an re-commit 
>>>> GenericBlockContext.
>>>
>>>
>>>
>>>
>>> I for one would like more time to consider this. Please tread 
>>> carefully dude given recent events. 
>>
>>
>>
>>
>> No problem. I'll continue the work on Merlin in the meantime - more 
>> to be done on documentation, demos, etc.
>
>
> Could you give us a an overview of these changes and their expected 
> usage, please Stephen?
> I'm having trouble seeing the immediate need.....


If you look at components like those found in Cornerstone, they have 
been written with the assumption that will be running inside Phoenix. 
Several of these components include specific Phoenix dependencies - for 
example, references to BlockContext. Looking closer you will find that 
Phoenix dependencies are almost 95% related to a component needed a 
reference to the application directory. As such you end up with frequent 
imports of BlockContext into components. Cornerstone is one example.

Merlin can deal with this providing the component declares the context 
criteria in a .xinfo or .xtype file (the .xinfo and .xtype can be 
considered as equivalent - .xtype exists only as a workaround to the 
existing Phoenix generate blockinfo descriptors that don't include 
context criteria). For example, I can write a .xtype file that declares 
that the component needs an instance implementing the BlockContext 
interface. With that in place, I can execute a cornerstone or James 
component by declaring context directives in the deployment file.

Lets look at a real cornerstone example:

DefaultSocketManager takes a context object and applies the object to
factories declared in its configuration. One of these factories is the
TLSServerSocketFactory which narrows the context object to BlockContext
without checking if the supplied context is a BlockContext - bingo -
ClassCastException.

By adding a .xtype directive, Merlin can told that the DefaultSocketManager
needs to be supplied with a context instance that implements the
BlockContext interface.

Within Merlin, when declaring the socket component, the assembler can
declare context creation directives. For example, an implementation of
block context only needs to be supplied with the block name and working
the directory.

Here is an example of a Merlin component declaration for
DefaultSocketManager:

<component name="sockets"
class="org.apache.avalon.cornerstone.blocks.sockets.DefaultSocketManager"
activation="false">

<context class="org.apache.avalon.phoenix.tools.export.GenericBlockContext">
<import key="app.home" name="avalon:home"/>
<entry key="block.name" value="store"/>
</context>

<configuration>
<server-sockets>
<factory name="plain"
class="org.apache.avalon.cornerstone.blocks.sockets.DefaultServerSocketFactory"/>
</server-sockets>
<client-sockets>
<factory name="plain"
class="org.apache.avalon.cornerstone.blocks.sockets.DefaultSocketFactory"/>
</client-sockets>
</configuration>

</component>

The above component declaration results in the definition of a
component profile - i.e. a component type together with
it's instantiation criteria. The context element declares to
Merlin how to build the context object. First of all, a context
implementation class (in this case a class implementing BlockContext)
together with directives that populate the context object with
keyed values.

When Merlin handles the establishment of the DefaultSocketManager
it creates a new instance of the context class (in this example an
instance of GenericBlockContext and populates a map with a
combination of explicit entry declarations and/or values imported
from the kernel.

The GenericBlockContext is independent of Merlin - in fact it's only
dependencies are to Phoneix (for BlockContext) and the Avalon
Framework (for Context). It follows the same pattern as the
framework DefaultContext (a map and a parent context
argument). In effect, GenericBlockContext enables other containers
to simulated the behavior of Phoenix for components that have
BlockContext dependencies.

The approach to handling this is either every container provides a
Phoenix workaround, or, Phoenix provides a utility class. The
intention was to approach this in a collaborative manner - Phoenix
providing the utility inside phoenix-client, Merlin providing the
mechanisms to handle context directives. If on the other-hand we
make it an obligation for every container to provide their own
Phoenix workaround, we will significantly escalate the number of
utilities and the approaches taken. It seems to me
that something like GenericBlockContext should reside in the phoenix
project because any component referencing BlockContext is dependent
on the phoenix-client.jar. If Merlin were to include this, then
a standard Merlin build becomes dependent on Phoenix. This increases
the overall size of Merlin with no benefit unless someone is running
a Phoenix dependent component (in which case they have already
declared phoenix-client.jar in their classpath).

There is another approach that I have discussed with some of the
people over on James - namely the usage of standard Avalon context
keys.

For example:

public void contextualize( Context context ) throws ContextException
{
File file = (File) context.get("avalon:home");
}

This would negate the necessity for inclusion of a container
dependency. But it does require that Avalon containers respect a set
of common context keys.

The common attribute approach would simply require that both Merlin
and Phoenix made sure that "avalon:"... context keys were made
available. E.g. DefaultBlockContext could be easily updated to
return the working directory in response to a "avalon:home" key.
This would eliminate the majority of container dependencies that exist
today. Complimenting this, a GenericBlockContext would provide an
elegant solution when dealing with components that include hard coded
dependencies on the Phoenix container.


I hope that provides a clear and complete picture.


Cheers, Steve.



>
> - Paul
>
>
> -- 
> To unsubscribe, e-mail: 
> <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:avalon-dev-help@jakarta.apache.org>
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message