Re: [A5:RT] Strategy for development

[Stephen McConnell]

Berin Loritsch wrote:

At the Apache WIKI I placed an outline for *how* I would like
the Avalon 5 system to be developed--which might have some
bearing on the Ubercontainer strategy as well. The link (if
you prefer HTML) is:

http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonFiveInterfaceProposal


For the rest of you, the text is here:

------------------------------------------------------------


= The AvalonFive Interface Proposal =

When we are separating code needed for compilation vs. code needed
for running a system, it makes sense to separate the implementation
from the interface definition. For this reason, I would like to set
up Avalon5 so that the person developing for it will have a jar with
a set of interfaces only. Not one implementation at all.

+1 (in principal)
There are a few primative classes that we may want to break this rule with - things like the Version class as an exmaple - but yes, I agree with the direction.

Why, you ask?  The actual implementation of the lifecycle interfaces
are many times container specific.  In fact, some interfaces in Avalon 4
have no real meaning outside of a container such as ServiceManager or
Context.

I'm rephrasing that to "some interfaces in Avalon 4 have no real meaning outside of the artificats provides by a container such as ServiceManager or Context." and asuming that my rephrasing is you intention.

 They represent what the container makes available to a
component.  Therefore the implementation is highly container dependent.

Agreed.

The fact that most of our containers do not use the "default"
implementation in the JAR leads to support that oppinion. It also allows
us to have focused "support" JARs.

This is a key thing - with the introdcution of a container API - the client should not being using things like DefaultContext - instread they should be wortking with the contaiment API and doing a clean seperation of client verus container side coding. Seperation of implementation from interface (contracts) reinforces the focus on using contains instead of coding your own interim solution.

== Focusing Support ==

The Logger interface allows us to successfully abstract the Logger
from the components that we write.  The fact that one component was
written against a container using LogKit doesn't mean that it will
be deployed that way.  A side affect of the current Avalon 4 structure
is that we currently need Log4J, LogKit, and JDK 1.4 Logging in the
classpath to compile for a distribution.  It would be better if the
backing logger abstraction was added in a separate JAR complete with
a LogManager that the Container uses to find the exact Logger
implementation necessary.

+1

We might consider leaving the "braindead" versions of the loggers
for debug purposes (i.e. NullLogger and ConsoleLogger). They can
be placed in a subpackage called debug or something.

I think this is an area that needs more work. As you know - the work in Merlin has created another approach to logging configuration - and the reson why ios that the existing models don't play well with an heirachical containement models - and they don't provide and formal metadata - both of which can be addressed but the place to address this is inside o.a.e.logger - not in Merlin or other container level packages.

It will also allow us to add support for certain environments.
For example, we might want a specific contract for containers
embedded in a Servlet context--i.e. where the values come from
for standard entries and accessing configuration values from
the ServletContext, etc.  By providing a "ServletSupport" JAR,
we can have the proper Logging formatters to glue into a Servlet
environment as well as provide proper context support for that
environment.

I would also like to see some migration toward "business-level" logging - notions of logging levels such as ALERT, NOTIFICATION, etc. Things that are more tangible to suits that what the framework currently provides.

== Pluggable Contracts ==

The concept of "pluggable contracts" is the process of having
a well defined <i>set</i> of contracts that we can use in a
given environment.  We always need the <i>constant</i> or
<i>guaranteed</i> contracts to act as a base.  The contract
sets that get superimposed on the base contracts are constant
for the environment.  If you change the environment, you get
a new set of contracts.

I'm reading the words and assuming that this is beasically the same as the notion of "strategy" that I've been dropping on this list from time to time. I'm thinking about a container that is hard coded at the level of strategies - and examples of strategies include A4 deployment, A5 deployemnt, etc. Inside a particular strategy you may find subsidary strategies - e.g. a strategy enabling lifecycle extensions or other concepts such a A4.1 lifestyle strategy (based on marker interfaces) versus a 4.2 strategy (mased on meta) - as examples.

At first this might seem contradictory to providing support
for cross-container components.  However, when applied correctly,
it helps containers provide a consistent environment to the
component regardless of the environment.

Refreasing this to - "it helps containers provide a consistent solution to the component adapter to its environment" - which is not what your said - are we thinking about the same thing ?

Let's look at Cocoon for example.  In a servlet environment,
it has added some abstractions to keep the components isolated
from the javax.servlet API so that it has the potential of
working from the command line and the Servlet environment.
The constant contracts are those guaranteed by the interface
abstractions.  The pluggable ones are those that map those
constant contracts to the environment.  The command line
environment provides a consistent set of contracts so that
the user knows how to customize it for their use.  The same
goes for the servlet environment.  The pluggable contract
sets are for how the container maps the environment to the
component, not for additional functionality supplied to the
component from the container.

And based on the above - I think we are thinging basically the same thing.

By standardizing component contracts strictly from the
viewpoint of the component (i.e. interfaces) we provide a
standard in which the component author can feel confident that
their component can work anywhere.

Yep.

But possible (more concretely) - we will be able to provide to the client developer the means throughwhich they can express constrains as to the environment thair component is applicable within.

By standardizing component contracts strictly from the
viewpoint of the environment to the container, we provide
a standard mechanism that any Avalon user will be able to
use to customize the environment. No extra coding is necessary,
the container can simply use the JAR that provides support
to the environment and everything is happy.
those defined by the interfaces.

There are couple of different things here:

* the computation environment
* the contutation model

The environment is talking about constraints wheras the model is talking about the vehicle through which solutions are delivered (e.g. A4.1 version A5) - but this is very esserteric so I'm going to sign-off!

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>