[kepler-dev] Refactoring Log4J Before 2.0.0

[Christopher Brooks]

I submitted an RFE for this awhile back, see:
http://bugzilla.ecoinformatics.org/show_bug.cgi?id=3903

However, I think it is too late in the game to make changes like this.
Kepler-2.0 should go out asap.  Is there anything further that needs to
be done for Kepler-2.0?

Converting from log4j to java.util.logging would be a great thing for
the development tree.

I'm fine with leaving the log4j jar file in the near term, though maybe
someday it would go away.

_Christopher

On 6/9/10 10:34 AM, ben leinfelder wrote:
> 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 yo
u
>
>    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
>>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev

-- 
Christopher Brooks, PMP                       University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841 fax:510.642.2718	      (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670