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>

Reply via email to