Hey Matt, I assumed JSON is default (or has higher priority than XML at least) based on documentation.
Log4j will inspect the "log4j.configurationFile" system property and, if set, will attempt to load the configuration using the ConfigurationFactory that matches the file extension. If no system property is set the JSON ConfigurationFactory will look for log4j2-test.json or log4j2-test.jsn in the classpath. If no such file is found the XML ConfigurationFactory will look for log4j2-test.xml in the classpath. If a test file cannot be located the JSON ConfigurationFactory will look for log4j2.json or log4j2.jsn on the classpath. If a JSON file cannot be located the XML ConfigurationFactory will try to locate log4j2.xml on the classpath. If no configuration file could be located the DefaultConfiguration will be used. This will cause logging output to go to the console. Sadly you did not catch sense of my question. Point was - how much configuration *formats* you gonna place in core, when people will opt for scala configuration dsl, what will happen? Anyway, it’s up to you how you drive your library. You might not see need to split core, that’s fine for me. Just remind that creation of "god-like” thinks is bad practice in software development regardless if it’s class, package or module. Best regards, Łukasz Dywicki -- l...@code-house.org Twitter: ldywicki Blog: http://dywicki.pl Code-House - http://code-house.org Wiadomość napisana przez Matt Sicker <boa...@gmail.com> w dniu 13 kwi 2014, o godz. 18:27: > XML is the default file format. You need to add the jackson libraries to get > JSON and YAML support. If people like YAML more than JSON, they're using the > same library, so it's perfectly alright! > > What would you mean by Groovy and Scala formats? You can already use Log4j2 > with any JVM language, and you can write your own custom implementation of > Configuration (though it's usually only done to support more file formats due > to the need to represent a parsed configuration file). > > Really, the parts that I think make most sense for modularity are any > packages that have optional dependencies. It's just that each optional > dependency tends to correspond to about 3-5 java files, so it seems pointless > to make entire JARs for each of those. I think that's the problem everyone > else is seeing. > > > On 13 April 2014 05:53, Łukasz Dywicki <l...@code-house.org> wrote: > Hey, > Please find my replies inline. I do reply on all mails at the same time. > > > >> I had a great idea inspired by Mark from Tomcat (forget his full name) in >> regards to splitting up core: we can set up a parallel repository that uses >> svn:external to organise the various packages into separate modules. Then >> separate pom.xml files can be written for these sub-modules. This might be a >> better route to go. > > I think you have spoken to Mark Thomas who did presentat few things. I also > spoken to Christopher Schultz who had tomcat monitoring presentation and he > is also tomcat commiter. He told me that Tomcat build is quite complicated > and that’s reason why they did not switch to maven. No need to mention how > big is build.xml for them. Main reason why their build is complicated and > hard to get it done is big core. > >> In Tomcat, they keep all their source code in one tree. However, their Ant >> build scripts build several JARs from that tree by pulling in various >> sub-directories. This is actually a big reason why they couldn't easily move >> to Maven (amongst other reasons I bet). It was suggested to make a parallel >> repository like I mentioned above. > > I don’t think that having source code in one tree is bad thing. Sometimes you > will have different releases having exactelly same code producing unecessary > traffic on maven repos and so on (we will let Sonatype pay for it ;-))). For > most of people it does not make a big difference. But on Tomcat build example > you can see a big technology debt. Multiple repositories are bringing some > extra effort to releases too. > >> Also, amusingly enough, Lucas, I've had quite a similar discussion here >> before. The main thing here is that nobody seems to think that core is large >> enough to be split. It's a different way of thinking about development when >> you move to OSGi. > > I can understand that. But you already see bunch of things which are sitting > next to each other having not that much in common. You can also take a look > on camel which is big project in apache having many dependencies. You might > run it under tomcat and they have fine grained dependencies. I never seen > anybody on their mailing lists considering that as mistake or wrong thing. > >> Also, if you drop Log4j into a web container currently it will automatically >> initialize in a Servlet 3 container. I’ve always been a bit uncomfortable >> with that and it was originally in its own jar, but others preferred it the >> way it currently is. > I do use log4j under tomcat as default logging backend also for container so > in the container I just need slf4j bridge since all apps I have made are not > dependant on logging backend. These times many libraries are already backed > to slf4j so it is even easier to go. > >>> Wait, some one is going to want to split each configuration format >>> processing into it's own module to reduce dependencies.. ;) Jackson is used >>> to parse JSON configuration files and JMX is currently defaulted to be >>> always enabled. > I don’t see this funny. How library is configured is one thing, how it is > used is another. Especially during development programmers do not touch log4j > configuration at all untill they have to apply log levels and so on (now with > JMX it’s easier), however then it is configuration. In 2.x you assume JSON as > default configuration, so it’s your choice but from my personal point of view > it is unecessary as I rather preffer property file. Having jackson embedded > in tomcat lib for people like me will just raise troubles as it’s popular > library used by many developers. > > It’s worth to answer following question: > - Will we put YAML/Groovy/Scala configuration format in core if donated? > - What we gonna do if people will love YAML more than JSON? > > Kind regards, > Łukasz Dywicki > l...@code-house.org > -- > Twitter: ldywicki > Blog: http://dywicki.pl > Code-House - http://code-house.org > > > > -- > Matt Sicker <boa...@gmail.com>
