Re: Log4j as "Source-Code Level" or "Compiled (black-box) Component" Reuse?

[Ceki Gulcu <cg...@urbanet.ch>]

At 07:56 23.01.2001 -0500, you wrote:

>So, I'm curious, of the two styles of reuse, what are folks doing?
>
>"Source-Code Level" - Just include the source code in your project, and make
>tweaks as desired (and do more work to upgrade to new versions as needed.)

This form of re-use is definitely tolerated: log4j comes with full source 
code and the license allows you to freely distribute your modified code. As 
a side note, you can fork log4j as long as you keep the APL license in the 
existing code and call your project something other than log4j. I think 
that the forking threat keeps maintainers on their toes which is a very 
good thing.

The disadvantage of this approach is that your changes will introduce 
different behavior event if with the standard log4j API. Unknowing 
developers are likely to get confused. Moreover, it might be well the case 
that log4j will be used in external libraries. These libraries might expect 
the standard behavior.

As a matter of principle, if you decide to change log4j core code, you 
should be aware of the consequences of these modifications. The chances are 
that if you go for ease of change then you probably don't realize the 
consequences of your modification.

I am sure that some changes that can only be done by tweaking the original 
source code.

>-or-
>
>"Compiled (black-box) Component" - Use the compiled framework as a lib for
>your project, and limit customization to the framework provided extension
>points (and drop-in replacement upgrade whenever desired, and only do some
>work when the framework breaks backwards compatibility.)

As I wrote in my previous mail, this from is supported actively. If log4j 
does not allow you to do something, this is considered as a design bug. 
Just let us so know and the "bug" will be fixed. Cheers, Ceki

----
Ceki Gülcü (cgu@urbanet.ch)