avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [A5:RT] Strategy for development
Date Thu, 09 Jan 2003 17:07:08 GMT

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:
>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
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.


>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.


>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

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.


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

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message