the gump build of log4j has been failing over the last few days. this has (in turn) lead to a large number of downstream build failures. this has alerted us to the fact that we're fast approaching the time where we will have to deal with supporting three binary incompatible major versions of Log4J.

i think that the time has come to adopt a more systematic approach to this problem.

i propose that Log4jLogger continues to support the CVS HEAD version of log4j but that we create Log4J12Logger and Log4J11Logger implementations supporting the two major Log4J versions out there. when log4j 3.0 alpha/beta/release candidate comes out, we add a Log4J13Logger to support the 1.3 series of binary compatible releases.

the LogFactoryImpl would then use reflection to make a best guess about the version of log4j present when checking for log4j and also when creating a Log4jLogger instance (a cheat to help backward compatibility).

i've take a look into the implementation details and i think that this plan could be done pretty quickly and easily. if no one else raises any objections, i'll complete and commit the implementation tomorrow.

i'm very open to suggestions about the best way to structure the build scripts.

- robert


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to