Hi Stephen, thanks for your response.
On Sunday 06 June 2004 04:02, Stephen McConnell wrote: > J�rg Hohwiller wrote: > > On Friday 21 May 2004 17:12, J�rg Hohwiller wrote: > >>Hi there, > >> > >>I am new to this list but have been using avalon + ECM in a project > >> before and plan to use avalon + merlin for my current open-source > >> project. > >> > >>I can see there is commons-configuration (which seems as it came from > >>avalon) and commons-logging. > > I think commons configuration came from Turbine (but I'm not sure). that's interesting... > > >>I saw in the archive that there was a > >>discussion about logkit vs. commons-logging + log4j before. > >>I would like to know if you are planning to directly use c-configuration > >>and c-logging in the avalon framework API? > > No plans and I can't see it happening. The Framework api Logger and > Configuration interfaces classes provide what is needed. However, you > can still use commons-logging and commons-configuration as part of a > component model by creating a lifecycle extension. okay. > > >>I personally think the commons initiative is a great thing and I can > >> still remember myself digging deep in apache projects sources to find a > >> ready to use cache, pool or whatever implementation. > >>Now why not just using these APIs as part of the avalon API? > > It would break the 4.X API with no tangible benefit - in fact it could > be argued that the end-result would be less valuable as commons > configuration and avalon configuration are very different animals. I actually was too quick and did not look deep enough into commons-configuration. You are right. It differs a lot. > > >>I can see that changing an API this way in general is a bad thing because > >>of loosing downward compatibility but on the other hand it is not a bid > >>thing to replace org.apache.avalon.framework.configuration to > >>org.apache.commons.configuration and org.apache.avalon.framework.logger > >>to org.apache.commons.logging (okay the last one is not just a string > >>replace). > > Commons Logging is about providing an abstraction layer above one or > more logging implementations. This is basically what the Avalon Logging > system is doing. The difference between Avalon Logging and Common > Logging is that Avalon Logging provides support for dynamically loaded > logging strategies. I just meant the APIs and I was thinking they are pretty much the same when I wrote this mail. > > A second issue is that the commons logging implementation classes and > API are not separated. If you mean not safely separated into different java packages, yes. > This results in the exposure of logging system > management apis to the client (which is not desirable). I have to admit that I do not understand this. What exactly do you mean with client here? > > Cheers, Stephen. > > >>Instead one could use adaptors that do the thing (I think there is one > >>available for configuration) but now if you want to use a specific > >>implementation of lets say c-configuration that allows also changing > >> parts of the configuration, etc. you can not access those features > >> across such an adaptor. > >> > >>So all I am suggesting is think about it. > >>Disscussions welcome... > >> > >>Take care > >> J�rg Regards J�rg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
