The disruptor might actually have to be an exception to the rule! You raise a great point. The async logger is one of the coolest new features, so we should probably bring that dependency in. We could go the Tomcat route and package-rename an internal version of it, or we could just keep an external dependency on it.
On 14 April 2014 16:24, Ralph Goers <ralph.go...@dslextreme.com> wrote: > While I agree in principal that may not be practical. For example, I > don’t know that that could be done with the disruptor, and to be honest > given the interest there seems to be in asynch mode I’m not sure that would > be a good idea even if it could be done. > > Ralph > > On Apr 14, 2014, at 2:19 PM, Matt Sicker <boa...@gmail.com> wrote: > > I feel as though anything that requires an outside dependency (other than > log4j-api) should probably be in its own module. The core should consist of > everything that is doable without dependencies outside Java SE. > > So, even though JMS uses Java EE, it could be its own module since that's > not standard Java SE. > > > On 14 April 2014 10: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. >> 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> > > > -- Matt Sicker <boa...@gmail.com>
