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>
