[kepler-dev] Refactoring Log4J Before 2.0.0

[ben leinfelder]

David -
Will you leave the log4j jar and properties files intact so that modules would still use that implementation even if it wasn't explicit in the code?
-ben

On Jun 8, 2010, at 11:00 PM, David Welker wrote:

> Hello All,
> 
> I was wondering if people think it would be reasonable to refactor out the use of Log4J and replace it with java.util.logging classes before the 2.0 release. As a general matter, I think we should probably stick to features provided by the JDK. More significantly, when providing technical support for a user who appears to be affiliated with Airbus, I found that Log4j was interfering with our scheme for allowing multiple class loaders in Kepler. I am not completely certain why this is the case at this point, but I speculate it has to do with some interaction between Log4J and the classpath (which it uses to read logging permissions, among other things). I suspect that when you split Log4J across the standard class loader and multiple class loaders, it crashes. This conclusion is reinforced by the fact that Log4J does not interfere when you specify that every single module have its own class loader. However, the problem with this "solution" is that it is much too slow. If you use multiple class loaders, it is important to use care not to use too many, as there is inefficiency associated with our custom class loaders compared to the standard class loader provided by the JDK.
> 
> Anyway, if no one objects, I would like to refactor all of the code in Kepler/CORE to use java.util.logging instead of Log4J. In this way, we will make 2.0.0 compatible with multiple class loaders and also eliminate a dependency. There has not been a huge amount of demand for multiple class loaders up to this point. But, the functionality does seem to be needed occasionally (like for the individual from Airbus) and it would be nice to support it.
> 
> Thoughts?
> 
> -David
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>