I, for one, am not upset by this discussion. As I have said, I have no objection to pulling some stuff out of core and I am thinking we need to start a companion project for “extra” stuff. That said, most Log4j users will expect that the core will contain roughly the same components that were in Log4j 1.x. But I am not convinced that JPA (or even SMTP) needs to be a core component. And I would probably be in favor of moving JMX out too, but I know it might be difficult to get consensus on that.
Ralph On Apr 14, 2014, at 7:42 AM, Matt Sicker <boa...@gmail.com> wrote: > 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 > 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 forma > > > > -- > Matt Sicker <boa...@gmail.com>