avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject RE: [A5:RT] Strategy for development
Date Thu, 09 Jan 2003 20:18:26 GMT
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Berin Loritsch wrote:
> >
> >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.

Right.  The distinction being whether these primitive classes are
*part* of the interface.  For instance, if we merge the Configuration
interface and implementation, we have made the new Configuration class
part of the *interface* for Configurable--even though it is a concrete

It is part of the contract, so to speak.

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


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

Right.  However if we define the areas in which the contract
needs refining, we can come up with a solution that works most
of the time.  If there are any alternatives, most of the time
they will be modeled after the solution that is in place.

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

I'd like to mention that most logging toolkits are meant for
developers/administrators to determine what is going on.  For
business level things (like ALERT, NOTIFICATION), we either
need a different tool, or a different channel.

For instance, if we have a Notifier component, it will disperse
messages at a business level.  It is a different tool so that
the process of business events is handled differently than the
general debug logs.

Currently, we can easily add a business specific channel.  Something
like "process.notification" and map logging levels to that channel.
The logging mechanism would handle that channel differently than the

I prefer the Notifier component because it is both business level,
and it can be customized to provide escalated notifications if
need be.  I think that it is a *component*, and not necessarily
something that the container itself needs to supply.

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

uh, yeah.  Different words I guess.  But yes, it is the strategy for
mapping an applications environment to the component/container

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

Essentially, but the phrase "to the component adaptor to its
environment" is very clumsily worded.  Could you clarify what
you mean?

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

Yes, through metadata.  In fact the same component can take on
new features depending on the environment.  The important thing
is to provide the base contracts to which it needs to be developed.

Not all components can or should be distributed.  The ones marked
with a "remotable" attribute would be exposed by a container that
supports that action.  Again, it is a strategy that is implemented
by the container--which in turn is affected by the environment.
A container that would otherwise be able to make components remotely
accessible to other VMs might be restricted by the security settings.
All the code is there, but the container wasn't given the priveledges
to expose the components on the wire.  Such a failure shouldn't
cause the system to cease to function, but merely reduce the

<off-topic constraint="important to consider">

One problem with very modular systems is security.  If a container
allows a high level of runtime resolution of features, there is
the ever present risk of a "rogue" JAR being put in the classpath
somewhere and performing a "Trojan" attack.  We need ways of
testing these modules/strategies and validating them--even if the
JAR was placed in the $JAVA_HOME/jre/lib/ext/ directory.  It
can be accomplished, but we need to provide extensions to the
normal JAR spec to allow us to validate them.  Failing securely
is very important.


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

Is that "computation model" or "continuation model" ?

However, you are correct.  There two different levels to consider.
The component/container relationship would be described as the
"Computation Model", while the container/environment relationship
would be described as the "Computation Environment"

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

Talk to ya later.

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