avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: On Multiple Containers
Date Thu, 21 Nov 2002 05:16:17 GMT


Nicola Ken Barozzi wrote:

>
> Federico Barbieri wrote:
> > thanks berin for being able to put toughts on keyboard better
> > than I do.
> > Thre must be a reason you're writing a book! :)
>
> Yes, thank you Berin, I agree with what you write. It also goes down 
> the path delineated by Noel IIUC.
>
> So it seems that the goal now is to understand the common ground 
> between info and meta, define a single descriptor that can act as a 
> merge point, and work with "clazz" and "attributes" in Jakarta Commons 
> for a more generic and possibly unified solution.


The clazz project has the potential to provide a single common unified 
solution within which the entire Avalon meta model can be expressed 
without the need to additional knowlege of specific Avalon meta classes. 
This has some specific implications - a meta-model defined using the 
clazz package becomes accessible to any tool or application within or 
external to Avalon providing it supports the clazz meta-meta-model. 
Secondly, particular properties of a Avalon metal-model could be easily 
extended. I've already started some playing around with the package 
(even posted through a patch a earlier this evening). I got in contact 
with the developers from the clazz project last week and a couple of 
them are already looking at what we are doing here in Avalon.

>
> We need a concrete comparison. I already did one some time ago and the 
> differences were minimal.
> Quick comparison about the info-meta descriptor now:
>
> * info has javadoc attributes; 


This is an area I've been avoiding prior to finalization of the 
meta-info model in excalibur/meta. The key thing that the info package 
provides in this area is validation of the generation of meta-info from 
javadoc tags - and that's an important feature. On the other-hand, if we 
consider clazz as the base for the meta-model, and usage of the 
attribute project content in dealing with javadoc additions, the 
generation side of the info package will be hit from two directions 
simultaneously. At this time I don't know if any work is going on 
related to javadoc driven generation of clazz meta info - but it is 
something that would a lot of sense.

>
>
> * in both there are inluded entries in the context;
>
> * both describe the possible casting of the Context, and it defaults 
> to avalon context;
>
> http://jakarta.apache.org/avalon/excalibur/info/doclet.html#avalon.context 
>
>
> * both have attributes;
>
> http://jakarta.apache.org/avalon/excalibur/info/attributes.html
>
> * meta includes stages/extensions, which could easily be a 
> container-specific feature with an external descriptor 


I would not use the term "container-specific" as the extension model is 
common to both Fortress and Merlin. These are meta-info structures that 
deal with an extension of a an Avalon meta-model and as such raise the 
technical requirement for a container to be able to recognize if the 
meta model it is supplied with is concrete or abstract (something I 
would like discuss further with the guys on the clazz project). For 
example, a component type may be based on an meta-model derived from an 
anstract Avalon meta-model (i.e. a clazz that cannot be instantiated).

However - there are solutions to the general meta-model extension 
question. If we look at Avalon components (extended or otherwise), there 
are specific things that containers do that are an abstraction of the 
data associated with the meta-info.

These things include (from the point of view of a container):

* verification
* assembly
* instantiation
* disassembly
* destruction

These notions can be expressed as meta-class operations. Using the clazz 
package, it is possible to introduce a differentiation between meta-info 
state and meta-model behaviors. For example, a container invoking 
verification on a class the includes a requirement for extensions should 
fail. In order to fail it needs to instantiated a verification handler 
the is specific to the model. In most cases the verification handler 
would default to an Avalon classic meta-model verifier - but in some 
cases (e.g. a component type that is dependent on extensions), the 
verification handler class would be derived from the classic handler and 
understand the notions of extensions.

What is common in this example - and what should be understood by 
containers - is the notion of a verification handler class, the way in 
which the handler class name is accessed, and the interface exposed by 
any verification handler implementation.


>
>
> * meta includes assembly orientated metadata for 
> context/logging/config declaration; it seems container-specific.


The classes in the excalibur/meta package fall into two categories:

excalibur.meta.info
excalibur.meta.model

The meta.info package is directly comparable to the info project 
content. The meta.model package deals with the seperate concern of 
deployment profiles. These classes exist here because they are *not* 
container specific - they deal with the general problem of aggregating a 
set of information (configuration, parameters, context, logging 
directives, etc.) that collectively defines a deployment profile. 
Equivalent abstraction exist within ECM, Fortress, and Merlin at the 
component type level.

>
> So, what is the difference in this descriptor?


Not a lot (at the meta-info level). There is one other item in your list 
that was not addressed. The excalibur/meta package includes support for 
the association of default configuration information to a particular 
type. This information can be supplemented in profiles and within 
assembly time configuration and presents a very important step forward 
in delivery of manageable component deployment. While I consider the 
"extensions" model as something that can be approached as a derived 
meta-model, the subject of defaults needs to be handled at the level of 
the core Avalon meta-model.

Second important point - what's the difference between what we have and 
a meta-model based on the clazz package? Quite a bit based on an initial 
assessment. The actual model generation process would be much the same 
except that instead of assembling the meta model using Avalon 
proprietary classes, we would be assembling a clazz meta model.

The key to this is to ensure that a builder is sufficiently flexible to 
enable the introduction of :

* different DTDs
e.g. the current Phoenix DTDs, a new Avalon DTD, maybe a clazz DTD?, and
possible the most interesting - a ECM DTD for the role abstraction

* defining a standard interface for a builder
For example, imagine the following:

interface ClazzBuilder
{
Clazz build( String path );
}

Not only does this isolate builder implementations from a classloader, 
but the type of object returned from the build process is an instance of 
the commons clazz project and is fully accessible based on the API 
exposed by the Clazz class. My initial impression is that there is a lot 
of room for collaboration with the clazz project on this area.

Finally, the notion of class level operations is something I think we 
should explore as this has the potential to abstract out the questions 
of meta-info and let us focus instead of meta-behaviour. This let's us 
achieve a complete separation of the issue of what type of component we 
are dealing with - it could be Avalon classic, it could be a Phoenix 
specific, a servlet, an ECM component, a Cocoon block, etc. These 
differences become an implementation detail of the Clazz in question and 
the notion of a container based component maangement contract becomes 
the focal point.

Cheers, Steve.

>
> Federico Barbieri wrote:
>
>> thanks berin for being able to put toughts on keyboard better than I 
>> do. Thre must be a reason you're writing a book! :)
>>
>> Berin Loritsch wrote:
>>
>>> Multiple containers are not only helpful, but they are absolutely 
>>> necessary.
>>> We will never be able to converge on the most generic and useable 
>>> container
>>> specifications when there is only one to choose from. Using different
>>> approaches that all work with the same components helps us to determine
>>> important criteria such as:
>>>
>>> 1) Is the component *truly* supported accross containers? I.e. with the
>>> same meta data specified the same way, will the component function?
>>>
>>> 2) Which core feature-set is *critical*? I.e. not all features for
>>> components
>>> are necessary in all situations. Which features can be ignored with the
>>> component still able to function as expected? The list of critical and
>>> _nice_ features help to determine what belongs in Framework. The 
>>> current
>>> Framework is definitely critical. The "Instrumentable" interface is 
>>> most
>>> definitely a nicety, but it does not affect the component's ability to
>>> function.
>>>
>>> 3) What is the best way to perform a function? Using the example of our
>>> pooling code, we had at one point three different pooling mechanisms.
>>> The best points from all three mechanisms were merged into one unified
>>> approach. If it goes in Framework, the interfaces must be correct, and
>>> any implementations need to be the best.
>>>
>>> Having multiple containers is not only workable, but they are 
>>> critical to
>>> the process of finding out what needs to be in framework and what is
>>> container specific. It will also help address the issue of how to 
>>> handle
>>> things such as component extensions in a cross platform way, and how
>>> to make the component still work if extensions are not used.
>>>
>>> Considering that Stephen and I (primary developers on the two competing
>>> containers in Excalibur) have proven that we are able to work with each
>>> other, I don't think we will run into any serious or unresolvable 
>>> problems.
>>> I believe that using metadata is the way to go, but I am not 
>>> convinced that
>>> either Meta or Info are the best way to express it. If we can come 
>>> up with
>>> one specification for how the meta information is *stored*, we can have
>>> multiple implementations like Meta and Info that make reading the 
>>> metainfo
>>> easier.
>>>
>>> I would propose working with the Jakarta Commons Clazz project to help
>>> implement class/method attributes. That would provide the best way to
>>> ensure a generic solution that is used and maintained by more than just
>>> Avalon. I think that is the best solution as it raises the synergy with
>>> Jakarta (whom we just left) and with each other. If a third party is
>>> maintaining that critical piece of code, then there is no chance of
>>> personality conflicts here. Furthermore, we are not the primary on that
>>> project so that it forces us to be on our best behavior (esp. if we 
>>> want
>>> commit privs for that project).
>>
>
>

-- 

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