Oh right, that is true. Well, you still need to provide the Jackson dependencies for JSON files to work.
I agree on the god library front, too. I just don't know how to get the point across without upsetting everyone. On Monday, 14 April 2014, Łukasz Dywicki <l...@code-house.org> wrote: > 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 <javascript:_e(%7B%7D,'cvml','l...@code-house.org');> > Twitter: ldywicki > Blog: http://dywicki.pl > Code-House - http://code-house.org > > Wiadomość napisana przez Matt Sicker > <boa...@gmail.com<javascript:_e(%7B%7D,'cvml','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 forma > > > -- Matt Sicker <boa...@gmail.com>
