avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrzej Jan Taramina" <andr...@chaeron.com>
Subject Re: [A5:RT] Strategy for development
Date Tue, 21 Jan 2003 15:46:40 GMT
Berin proposed:

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

I agree.....this provides more modularity and flexibility.

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

I must admit, I'm a bit surprised that the interfaces and implementations are 
packaged together in the current version.  Have you implemented this 
separation in the preliminary A5 jar that you posted a while back?

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

Why not call it a LogManagerFactory, to comply with common naming 
standards?  See comments above...I'm surprised that this is the case in the 
current release.

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

The NullLogger may be used in production deployments, so I would not put it 
in a debug subpackage. Better to put it in logging.logManagers or some such.

> == 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 would also suggest that the collection of "guaranteed" or "mandatory" 
contracts that make up the base for the framework be as small as possible, to 
engender the maximum amount of modularity and flexibility.


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


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


Mime
View raw message