Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
From: =?iso-8859-1?Q?Vincent_Tenc=E9?= <vtence@pyxis-tech.com>
To: "Apache Directory Developers List" <directory-dev@incubator.apache.org>
Subject: RE: SystemBackend.java Picoification
Date: Wed, 3 Dec 2003 10:49:38 -0500
Message-ID: <DKEHLBLNMNHHCEEIIIGOMEKGCAAA.vtence@pyxis-tech.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: 
 <20031203143941.IUYZ1942.imf23aec.mail.bellsouth.net@mail.bellsouth.net>
Importance: Normal

Paul,

I'm really interested in your approach. IIUC correctly, we're trying to
share common mechanism by inheritance and have different component "front
ends" to support different containers. I have been thinking recently on the
best way to make the AAA framework both Pico and Avalon compatible. I was
hoping we could support both containers in a single implementation (as
opposed to having PicoContainer and Avalon implementations), for the sake of
simplicity, and that's the path I have investigated. The downside of it is
that as we add support for different containers, it might not always be
possible, so I don't know if this is something we would like to do. You
surely have think of this before.

I have questions about the logging and configuration concerns:

1. In your example, I am assuming that some Pico front end will resolve the
configuration details to build the configuration bean. OTOH, the Avalon
implementation takes care of the configuration itself. Would it be possible
to have a unify configuration mechanism? There is a way to do this using
XStream, but that would impose constraints on (and rework of) the XML schema
of the components configuration.

2. If we want to do logging in the Pico implementation, we need to provide a
Monitor2Logger adapter. So we need a mechanism in the Pico front end to
configure the component with the correct adapter. Is this something that
exist already in one of the nano container sub projects? Also, how do we
handle logging in the abstract component implementation? We can't use a
logger, so we would have to use the monitor, so we end up having to use the
adapter for the Avalon implementation as well.

See, I'm still a bit in the dark here ;-)

- Vincent

> -----Original Message-----
> From: Alex Karasulu [mailto:aok123@bellsouth.net]
> Sent: Wednesday, December 03, 2003 9:40 AM
> To: Apache Directory Developers List
> Subject: Re: SystemBackend.java Picoification
>
>
>
> Paul, thanks for the example.  Vince what do you make of this
> mechanism since you have been working on the AAA stuff to make
> it work with both Merlin and Pico?
>
> >
> > From: Paul Hammant <Paul@ThoughtWorks.net>
> > Date: 2003/12/03 Wed AM 04:28:04 EST
> > To: directory-dev@incubator.apache.org
> > Subject: SystemBackend.java Picoification
> >
> > Folks,
> >
> > It took about 45 mins.  And is attached.
> >
> > I've checked sandbox1 and made a single mod for the component
> 'SystemBackend'. It has been renamed to AbstractSystemBackend and
> is extended by AvalonSystemBackend and PicoSystemBackend.  Best
> to look at those last two to se the fundamental difference betwen
> type1 and type3 IoC.
> >
> > The SystemBackendConfig object is a style preference. Another
> strategy is to pass its two parameters directly into the ctor of the comp.
> >
> > SystemBackendMonitor is a design best described here
> http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonNoLogging by
> Leo Sutic. I don't do logging anymore for resuable components.
> Not Log4J, nor CommonsLogging, no 1.4Logging. I do monitoring.
> Logging to one of those mentioned is one choice. So is the
> NullObject pattern. A choice for the deployer/assembler, not for
> the component coder :-)
> >
> > Regards,
> >
> > - Paul
> >
> > --
> > http://www.thoughtworks.com -> The art of heavy lifting.
> > Home for many Agile practicing, Open Source activists...
> >
> >
> >
>