[kepler-dev] Refactoring Log4J Before 2.0.0

[David Welker]

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