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.
Ralph On Apr 12, 2014, at 7:20 AM, Ralph Goers <rgo...@apache.org> wrote: > Jackson is used to parse JSON configuration files and JMX is currently > defaulted to be always enabled. > > Ralph > > On Apr 12, 2014, at 3:24 AM, Łukasz Dywicki <l...@code-house.org> wrote: > >> Ralph, >> For these who wants a "big” log4j you might provide aggregate JAR just like >> astyanax does. I think it’s much easier going this direction than other way >> around. Fine grained dependencies are proof of good library design. In slf4j >> epoch developers do not depend on any log4j code except test scope where >> mostly used is FileAppender. During deployment time it doesn’t make big >> difference too because only one place which would be affected is assembly. I >> can also imagine that some people could still love spring log4j stuff and >> will not need direct log4j support for it. >> >> I can understand that disruptor might be mandatory to provide asynchronous >> behaviour but why JMX and Jackson could not be separated? >> >> Best regards, >> Łukasz Dywicki >> -- >> l...@code-house.org >> Twitter: ldywicki >> Blog: http://dywicki.pl >> Code-House - http://code-house.org >> >> Wiadomość napisana przez Ralph Goers <ralph.go...@dslextreme.com> w dniu 12 >> kwi 2014, o godz. 06:26: >> >>> There is a balance that needs to be struck here. We don’t want to add >>> support for OSGi at the cost of forcing non-OSGi users to have to include a >>> bunch of Log4j dependencies. That said, I suggest the other day that we >>> might want to split some things that a majority of our users will rarely >>> use into other modules, possible in a companion project to the Log4j kernel. >>> >>> We actually have a few dependencies, such as Jackson, the disruptor, and >>> JMX that are optional but really can’t be separated from the core. >>> >>> That said, an analysis of what could be separated is warranted. >>> >>> Ralph >>> >>> On Apr 11, 2014, at 3:40 PM, Łukasz Dywicki <l...@code-house.org> wrote: >>> >>>> Hey all, >>>> Apachecon has been ended so I am following the promise I did - I’ve taken >>>> a look on the log4j build to check what’s going on with OSGi stuff. >>>> Currently OSGi bundles are split from main log4j-core which I think leads >>>> to maintanance trouble also number of dependencies of log4j-core seems to >>>> be very high. If we could split the log4j-core into smaller modules >>>> (mongodb, jms, jmx, web) then there will be no need to keep log4j-osgi and >>>> it’s submodules. >>>> According to maven guides [1] "Optional dependencies are used when it's >>>> not really possible (for whatever reason) to split a project up into >>>> sub-modules”, I think it will also make library design much more clear and >>>> will avoid making unecessary inner code deps. Seems that big, aggregate >>>> modules, are always grow to size which require major work to split them to >>>> make both: maintanance and community involvement possible. >>>> >>>> [1] >>>> https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html >>>> >>>> Cheers, >>>> Łukasz Dywicki >>>> -- >>>> l...@code-house.org >>>> Twitter: ldywicki >>>> Blog: http://dywicki.pl >>>> Code-House - http://code-house.org >>>> >>> >>
