[kepler-dev] Refactoring Log4J Before 2.0.0

[David Welker]

Yeah. That is probably more sensible. It didn't seem like a big  
project to me, but you never know.

Sent from my iPhone

On Jun 9, 2010, at 1:43 PM, Derik Barseghian  
<barseghian at nceas.ucsb.edu> wrote:

> I vote Nay for doing this pre-release as well, I'd like to see us  
> release asap. Why not do this as a patch after release?
> Derik
>
> On Jun 9, 2010, at 10:39 AM, Christopher Brooks wrote:
>
>> 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
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>