Gang, Trying not to be sarchastic or disrespectful, and only giving a hint of how I perceive stuff at the moment.
Currently, the Log4J project is in a disarray and conflicting messages are being sent to the users. IMHO, SLF4J is a hasty conversion of UGLI and has not gotten much feedback from the JCL camp, as was hoped for. And I seriously think that SLF4J is a well-meant mistake. Bring the "static linking" concept over to JCL instead, into a version 2 (or 3) and leverage the market that JCL in fact has. It should be much different than the now competing approach. Log4J should continue its current approach of being an implementation, and hopefully get a slightly better focus on "breaking apart" the internals, so that it consists of; 1. a toolkit of useful parts. 2. one (or more) ready-to-deploy solution(s). but the parts in the toolkit could be used in other deployment scenarios, for instance in the fields of configuration, framework integration or minimalistic deployments. The current affair of; * Log4J 1.2.10 -> 1.2.11 * NLog4J * SLF4J native or facade support * various flip-flopping of version numbers * introduction of new features in a 1.2.x point release. is bad for the market. This can't be hard. Cheers Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
