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:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
