directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <P...@ThoughtWorks.net>
Subject Re: SystemBackend.java Picoification
Date Thu, 04 Dec 2003 11:41:48 GMT
Vincent,

>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 like the style I have done as it reduces the jar bloat of a for users 
of teh frameworks in question.  For example, Pico users would not like 
to see avalon-framework.jar as a requirement for using directory/ldapd

>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.
>  
>
Pico's ideals do not force an assembly or configuration choice.  See 
unit tests in this NanoContainer package 
http://cvs.codehaus.org/viewcvs.cgi/nano/nanocontainer/src/test/org/nanocontainer/?root=nanocontainer

We have JavaScript, XML, and Jython assembly designs being evolved. 
Pnuts, NetRexx, BEanshell, and Groovy ones to add.  Each makes it's own 
design.  Look for 'WebServerConfig' as a term in the source. You'll see 
several designs. The one that is most Avalon like is in the XML test 
case and uses Joe Walnes' (Java Open Source Programming book) XStream 
tool. It will take a few minutes to poke thru the pertinent source, but 
might be worth it to understand our vision.

So in short, we are more interested in an open config design, rather 
than the closed Configurable design of Avalon (or similar).  
WebServerConfig is an interface with getters. There are bean and ctor 
impls, as well as one that XStream used that is just private member 
vars.  Additional ones may be PropertiesFileWebServerConfig, 
XmlFileWebServerConfig, RemoteWebServerConfig etc.

>2. If we want to do logging in the Pico implementation, we need to provide a
>Monitor2Logger adapter. 
>
Yes.  If you embrace entirely the Monitor design, then yes. However I 
have coded it only for the Pico concrete impl. The Avalon one still uses 
the A-F logger natively. As I say I hate logging nowadays :-)

>So we need a mechanism in the Pico front end to
>configure the component with the correct adapter. 
>
Yes.  In AltRMI (also in incubator), there are many classes ending in 
Monitor that gove a pluggable choice.

>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? 
>
Nothing automagic.  I have never found it too costly when using IntelliJ.

>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.
>  
>
Not the way I have coded the refactored AvalonBackend (is uses plan A-F 
logging). 

>See, I'm still a bit in the dark here ;-)
>  
>
Tis only a pico issue, unless you end up hating logging too.

- Paul

-- 
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


Mime
View raw message