I know that our programmatic configuration does not seem simple. I see more clearly now what you are doing.
I am not sure what the best solution is. Evolve our current api, or layer one on top like you just did. By the time a new api would support all of log4j it would grow quite a bit! My initial inclination would be to make our current api more usable. Unfortunately I do not have the bandwidth to dig into a new project atm. I hope other can provide more constructive feedback. What say you log4j devs? Gary <div>-------- Original message --------</div><div>From: Behrooz Nobakht <[email protected]> </div><div>Date:03/08/2015 08:58 (GMT-08:00) </div><div>To: Log4J Developers List <[email protected]> </div><div>Cc: </div><div>Subject: Re: Apache Log4j 2 Configuration Builder with no configuration file </div><div> </div>Hi Gary, Thank you for your feedback. > Java docs and other ambiguous issues I pushed some changes: (a) added Java docs (b) added a couple of examples to the README.md and as a Java source in the test folder. https://github.com/nobeh/log4j-configuration-builder > Regarding the limitations When I started to do this, my main motivations were: 1. Try to drop the need to have a log4j.xml 2. Simplify the glue code that is needed to wrap around Apache Log4j API to prepare a LoggerContext for use 3. Use convention over configuration Based on the above, my usual cases were: - Quickly get a console logger with debug level - Deliver the application artifact in an **embedded** mode with safe default configurations Using the "convention over configuration" approach above, in the debugging/development mode, usually the file appender with/without a strategy is anyway overlooked. When in live mode, the default daily rollover with 30 maximum days to keep seemed to be a reasonable default. That's why - The current implementation does not support syslog appenders yet. - ~ does not support database appenders yet. - ~ does not support simple file appenders yet. If you see the potential, I can work on the implementation to cover some general use cases that are expected to be. The above also somehow addresses how much effort is required to make this part of Core API. Let me know. Thanks, Behrooz On Mon, Mar 2, 2015 at 6:27 PM, Gary Gregory <[email protected]> wrote: Thank for pointing out your work. The lack of Javadoc makes it hard to understand what the builder does or what is the intent of its scope. For example: builder.addAppender(extraAppenderName, "myapp-extra.log", "myapp-extra.log.%d{yyyy-MM-dd}"); Does that always create a rolling file? What if I want to log to a simple file? Or logging to the console? To a database? How broad is the builder supposed to be? Is there a way the Core's config code could be made better to either make this builder redundant or easier to write? Thank you! Gary On Mon, Mar 2, 2015 at 7:01 AM, Behrooz Nobakht <[email protected]> wrote: Hi, It's been a while that I've been using Apache Log4j 2 using no configuration file. This is quite useful in the context of embedded services and small application. Basically, all the configuration is done via code and using standard Apache Log4j API. I thought it might be good to extract a very small module to present how I have done this so far. The result is available at https://github.com/nobeh/log4j-configuration-builder I'd be happy to work on it further as a contribution to the core library and consider it to be merged into the library. I'd appreciate your feedback and thoughts on this. Thanks, Behrooz -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- -- Behrooz Nobakht
