You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by "Schudt, Christian" <Ch...@cgm.com> on 2015/12/02 10:54:32 UTC

Issues found while migrating to 2.4.1

Hi,

I am migrating log4j 1 to version 2.4.1 and found a few issues, that I like to share.

1. The code found under "Programmatically Modifying the Current Configuration after Initialization" does not compile:
https://logging.apache.org/log4j/2.x/manual/customconfig.html#AddingToCurrent


2. I've stumbled over the exact same problem as described here:
http://mail-archives.apache.org/mod_mbox/logging-log4j-user/201308.mbox/%3CCAAqLGLN9ai8teRZWcdVGszHZcQRErJ841qXT+RbVaufPQs0HWA@mail.gmail.com%3E

It would be nice if the API could protect against this error.
It's non-obvious that one *must* override "Configuration getConfiguration(final String name, final URI configLocation)".


3. Programmatic configuration feels messy and it's not easy to get it working. I've tried everything in https://logging.apache.org/log4j/2.x/manual/customconfig.html
In the end my only working solution is, that I *must* have a log4j2.xml file, because otherwise log4j complains with "No log4j2 configuration file found. Using default configuration: logging only errors to the console."
I then reconfigure log4j using "ctx.getConfiguration().getRootLogger().addAppender()" etc...

Reconfiguration using the Configurator.initialize() method didn't work as expected. Log entries were still written as defined in log4j2.xml.


4. The API feels poorly conceived. E.g. RollingFileAppender.createAppender() takes way to many parameters (15) for my taste and on top of that it uses String for nearly everything (especially boolean), so that you have to pass a String "true" instead of simply true. The same goes for DefaultRolloverStrategy.createStrategy() where you have to pass an integer "max" as String.
I was hoping for some builder to create a RollingFileAppender, but the best I've found is AppenderComponentBuilder, which doesn't build an Appender, but a Component and suffers from the same problems (addAttribute methods are too generic).

Also should BuiltConfiguration not be BuildConfiguration? 

Should I post this on the dev list?

Thanks for your thoughts,
Christian




---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: Issues found while migrating to 2.4.1

Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Dec 2, 2015 at 4:54 AM, Schudt, Christian <Ch...@cgm.com>
wrote:

> Hi,
>
> I am migrating log4j 1 to version 2.4.1 and found a few issues, that I
> like to share.
>
> 1. The code found under "Programmatically Modifying the Current
> Configuration after Initialization" does not compile:
>
> https://logging.apache.org/log4j/2.x/manual/customconfig.html#AddingToCurrent
>
>
> 2. I've stumbled over the exact same problem as described here:
>
> http://mail-archives.apache.org/mod_mbox/logging-log4j-user/201308.mbox/%3CCAAqLGLN9ai8teRZWcdVGszHZcQRErJ841qXT+RbVaufPQs0HWA@mail.gmail.com%3E
>
> It would be nice if the API could protect against this error.
> It's non-obvious that one *must* override "Configuration
> getConfiguration(final String name, final URI configLocation)".
>
>
> 3. Programmatic configuration feels messy and it's not easy to get it
> working. I've tried everything in
> https://logging.apache.org/log4j/2.x/manual/customconfig.html
> In the end my only working solution is, that I *must* have a log4j2.xml
> file, because otherwise log4j complains with "No log4j2 configuration file
> found. Using default configuration: logging only errors to the console."
> I then reconfigure log4j using
> "ctx.getConfiguration().getRootLogger().addAppender()" etc...
>
> Reconfiguration using the Configurator.initialize() method didn't work as
> expected. Log entries were still written as defined in log4j2.xml.
>
>
> 4. The API feels poorly conceived. E.g.
> RollingFileAppender.createAppender() takes way to many parameters (15) for
> my taste and on top of that it uses String for nearly everything
> (especially boolean), so that you have to pass a String "true" instead of
> simply true. The same goes for DefaultRolloverStrategy.createStrategy()
> where you have to pass an integer "max" as String.
> I was hoping for some builder to create a RollingFileAppender, but the
> best I've found is AppenderComponentBuilder, which doesn't build an
> Appender, but a Component and suffers from the same problems (addAttribute
> methods are too generic).
>

Yes, we could use builders if you want to use builders instead of using a
config file.

Take a look at the SocketAppender class in git master, it has been changed
in the same line you suggest while keeping backward compatibility. You can
provide patches for the classes you care about in the same style.

Gary


>
> Also should BuiltConfiguration not be BuildConfiguration?
>
> Should I post this on the dev list?
>
> Thanks for your thoughts,
> Christian
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory