avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: organisation of avalon subprojects
Date Tue, 02 Jul 2002 01:40:00 GMT


Peter Donald wrote:

> At 09:04 AM 7/1/2002 +0200, you wrote:
>
>>> Even if you want to work around this you can use multiple strategies 
>>> - a container wide mapping (ie all components who want the 
>>> ****INTERFACE*** org.apache.cocoon.CocoonContext get an instance of 
>>> org.apache.merlin.CocoonContextImpl).
>>
>>
>> Meaning I add container specific workarounds for every container I 
>> know about - BAD BAD BAD.
>
>
> you are going to have to anyway as no container specific context 
> implementation will be instantiatable via a no args constructor. The 
> whole point of container specific context is that the container offers 
> container orientated services (like proxing) or data (like 
> ClassLoaders or MBeanServers) that can not be gained via peer 
> components/Composable or via Configuration. 


I'm talking about a context interfaces and context entries that a 
component declares in accordance with the component info mata model. 
Every interaction between a container and the components it is managing 
for a part of the overall model. In the case of configuration, the 
component model says that a component will be supplied with an instance 
of Configuration - the same case for Parameters. The component info 
model does not currently place any constraints on these argument - 
however, the component info model does place constraints on the context 
argument - the supplied context instance must implement a specific 
interface and must include certain names entries. This is a declaration 
FROM the component type TO the container. It is the declaration by the 
component of the responsibility of the container towards the component 
and is declared as part of the formal component meta model:

http://home.osm.net/doc/containerkit/org/apache/excalibur/containerkit/metainfo/ContextDescriptor.html

We have already the ability to create context objects that are 
completely 100% consistent with the meta-info criteria desribed by 
ContextDescriptor. Using a parent context object we can easily provide 
the ability for a container to provide added-value stuff via context to 
the components it is managing - but that is orthogonal to the question 
of ensuring that the final context object that is created is consistent 
with the components expectations. For example, if Phoenix or any other 
container is supply really sophisticated way cool extra value to a 
component via context - the container can build and declare this inside 
a root context object. The container then proceeds with the issue of 
resolving the context criteria required by the component - it does this 
using the context creation utilities we already have. The final context 
is created using the container context as the parent - and the context 
instance is supplied to the component. The container is happy and the 
component is happy.

>
>
> You are never going to be able to support these sorts of features 
> without inbuilt support by the container. 


Let's assume that someone writes up a new component - they do a nice 
job, they base the patterns they use on component examples available in 
Avalon. The end result of that work is (for the purpose of the 
discussion) a component that is published with a particular schema for 
its configuration, doesn't use parameters and its serviceable or 
composable, but does declares that it needs a set of values as part of 
the context it is supplied with. If we look around Avalon, we will see 
several components that do this (a bunch were listed in the email you 
replied to). Others include the Merlin component, the Avalon Apps ORB 
component, etc. If we look at this new component in isolation (i.e. 
independently of containers) - its a perfectly reasonable component. The 
developer in question can create and deploy this component by using the 
typical practice of creating the configuration, creating a new context 
object, populates the context object with whatever is needed, applies 
the context and the configuration and initializes the component. Fine - 
everything is working as expected and complete consistence with the 
framework documentation. Lets assume that out "sample" developer does 
ahead and builds another 18 components, starts getting into more complex 
scenarios - and starts thinking to him/her self that perhaps it would be 
a good idea to use a standard container. So out developer heads over to 
the Avalon site and checks out the information about what it means to be 
a standard-component in a standard-container. Our developer reads 
through the definition of an xinfo file - sees information about how 
he/she can describe the dependency constraints, services provision 
declaration, context constraints, and type attributes.

 From this information our developer writes up the following xinfo 
descriptor:

<component-info>
<component>
<context type="MyContextInterface">
<entry key="base" type="java.io.File"/>
</context>
</component>
</component-info>

Ok - so far our developer is simply using the containerkit model of a 
component definition to define the responsibilities that a container has 
towards his/her component. The above declaration is saying that in order 
to deploy this component, the host container must be able to supply the 
component with a context object that implements the interface 
MyContextInterface, and, that context object must contain a context 
entry with the key name of "base" and the value returned must be an 
object of the type java,.io.File.

Our developer understands that he/she has to provide additional 
information at the assembly level that provides things the configuration 
to be used for the component and other construction criteria. So out 
developer does ahead and includes a <component/> entry directive in 
containers assembly file. That component entry includes the information 
about how the component should be configured and how the component 
should be contextualized.

For example - a component declaration in an application descriptor:

<component name="my-component" class="org.somewhere.MyComponent">
<configuration>
Any configuration information our developer wants goes here.
</configuration>
<context class="MyContextClass">
<entry key="base" type="java.io.File"/>
</context>
</component>

Using the above information, the container can instantiate an instance 
of MyComponent, can build the configuration based on the configuration 
element included in the component declaration, and can build a context 
using the information supplied in the <context/> element though 
utilities such as ContextFactory 
(http://home.osm.net/doc/merlin/org/apache/excalibur/configuration/ContextFactory.html). 
When the container executes the validation of the component in 
accordance with the containerkit component info model - it can check 
that the required context entries are available, and that the context 
object it has prepared implements the required interface. Based on this 
assessment, the container can process with component lifecycle execution 
in the knowledge that all of the component type constraints have been 
fulfilled.

Reviewing the above case:

1. a container will have to deal with <context/> constraint declarations 
during validation.
2. Several Phoenix based components directly reference the context 
interface BlockContext and will need to declare this interface 
dependency and the corresponding context creation criteria - or - remain 
bound to Phoenix and no other container.

I don't see how you can work around this. Either the problem is 
addressed or we are really wasting our time. If you have a solution - 
educate me. But please don't tell me that its Ok for Phoenix to publish 
a BlockContext and then go ahead and tell me that this is a container 
issue because it simply isn't. The fact that the Phoenix BlockContext 
interface is public means that it will be used - just as 
ServiceLoaderContext is public and will be used. These context types 
imply a relationship between the container and the component - and 
that's what all of this is about - identifying and resolving a standard 
set of semantics between the container and the component.

Please - please - explain how this will be addressed - I'm totally lost 
in trying to figure out your objections here .It the issue is technical 
- please explain what you see the problem being - if the issue if 
architectural - please explain what the impact is that I'm obviously 
missing. If the issue is something else - please explain it because I 
just not getting it.

Cheers, Steve.

-- 

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