Hi Mario I think it is because in this way (having this logger-abstraction in the myfaces-jars) it is possible to eliminate the runtime-dependency on commons-logging in an easier way.
If, as deployer, I do not want commons-logging in the container, at most I write two dummy-classes which replace Simons classes. And that's it... Therefor: great work Simon regards Alexander -----Original Message----- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: Thursday, December 15, 2005 8:53 AM To: MyFaces Development Subject: Re: Loggers in API Components Hi Simon! Why wouldnt you create this wrapper library under the umbrella of commns-logging? Different commons-logging libraries using static linking instead of the dynamic behaviour. Say: commons-logging-log4j, commons-logging-jdklogger That way we still can use the well known LogFactory and every other project will benifit from this too. One can replace the logging implementation used just by replacing the jar. I think it isnt that a good idea if every project comes with its own wrapper library. In the worst case this will double the number of libraries used - even more logging hassle. just my 2ct. Mario
