[kepler-dev] Refactoring Log4J Before 2.0.0

[Derik Barseghian]

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