Folks, Some obersvations :
Page http://jakarta.apache.org/avalon/ ---------------------------------------- 1) Sub-Projects "logkit" before "Framework". Framework is our major art, it should be first. 2) "Logkit" I think some front page addition to the effect of : LogKit is the preferred logger for Avalon sub projects and components. It is not a static logger like that other popular one that Apache hosts, because we prefer one that is true to our IoC pattern. It is interface/impl separated and can redirect its logging to that aforementioned static logger or to various other implementations local and remote. 3) "Excalibur" I think the addition of - These components can be used in client or server side Java applications that in all other senses are not dependant on Avalon. For server side Java, they can be used in the Servlet context or fully blown server applications. 4) "Phoenix" - Pheonix is a Application Server for other Servers. .... composed of blocks... 5) "Cornerstone" ... can be used to build your own server for phoenix (i.e. drop starting point). 6) "Testlet" - can we purge this ? 7) "Applications". New section. Page http://jakarta.apache.org/avalon/framework/index.html ------------------------------------------------------------- 1) "Target Audience" Is now : This documentation is aimed towards developers who are interested in the design principles of Avalon, or wish to develop code that will be incorporated into Avalon Should be : This documentation is aimed towards developers who are interested in the design principles of Avalon, or wish to develop code that will be incorporated into Avalon, or reuse Avalon concepts in their own application. 2) "Theoretical Aspects of Component Development" I'd like to add a new pattern that we already informally treat reverently. It is "Interface/Impl seperation". People understand it but do not really apply it, of it is mucked up. Catalina, for example, is supposed to be interface/impl separated but is (or was last time I was active in their mail list) not. The other thing that wven we are historically a bit guilty of is the separation in terms of jars. We desire this because we want to hide implementation. Following of from Peter's K/CAPI/HC trinity of classloaders, where Hosted comps (HC) only see the Client API (CAPI), the Kernel (K) may have chosen to hide the impl of the CAPI in a different clas loader, not just by dyanmic proxy. The K/CAPI/HC trinity will be repeated many times over in the most complex cases (Phoenix hosting JAMES, FtpServer, Jesktop, EOB). It would be good if we could really start promoting this. At least I am getting sick of explaining it to the people I meet on the net when they have something that is almost a good candidate for an example for EOB. One case wherewe have it wrong is I think cornerstone.jar, it contains interface and impl and will probably be left as is for historical reasons. I think I have created enough trouble for one day.... ;-) Regards, - Paul H -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
