I think your approach is reasonable - JMS is not used in desktop applications often. Even in Tomcat which is web container it’s very rare to run JMS for logging. I don’t have any objections to disruptor dependency. Documentation will need to enlist JARs which have to be present on classpath to make particular appenders running. For developers it’s straight forward because maven does great job, but for administrators setting up for example centralized tomcat logging will be very helpful.
Thank you very much for cooperation! 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 15 kwi 2014, o godz. 01:05: > JMX is part of Java SE. I think it should work fine. The GUI can still be its > own JAR as it's needed for JConsole, but the MBeans and such work fine in > Java SE. > > > On 14 April 2014 17:15, Remko Popma <remko.po...@gmail.com> wrote: > > > On 2014/04/15, at 0:21, Ralph Goers <ralph.go...@dslextreme.com> wrote: > >> 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. > > Are you aware that JMX does not require any external dependencies? > > The JMX GUI does need the JDK tools.jar to build (so it can be run inside > JConsole as well as a standalone app), and we already moved it to a separate > module... > > From a dependencies point of view there is no reason to move JMX out of core. > > Remko > > Sent from my iPhone >> >> 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> >> > > > > -- > Matt Sicker <boa...@gmail.com>
