Re: [A5:RT] Strategy for development

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