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>
