Yes, J1 and J2 are in different packages, but Core IS using v2. log4j-core has a compile-time dependency on 2.x and NO dependency on 1.x (previously its compile-time dependency was on 1.x). This temporarily (locally) broke compilation in the JSON config classes but I changed the import statements, tweaked the API usage, and that was resolved. So log4j-core IS using 2.x.
It's perfectly safe to have 1.x and 2.x on the class path at the same time, but for compile and test purposes, log4j-core ONLY has 2.x on the class path and log4j-flume-ng ONLY has 1.x on the class path. Nick On May 16, 2013, at 12:28 PM, Gary Gregory wrote: > FWIW, it look like Avro 1.7.4 still depends on Jackson 1.8.8. > > I'd go with solution (3) and let other dependencies catch up to modern > versions of Jackson but... > > It looks like J1 and J2 are in different packages right? v2 in > com.fasterxml.jackson and v1 in org.codehaus.jackson? > > So if you changed a dependency from v1 to v2 and did not change import > statements, you are NOT using v2. > > Gary > > > On Thu, May 16, 2013 at 1:17 PM, Nick Williams > <nicho...@nicholaswilliams.net> wrote: > So this is all kinds of fun... > > log4j-core depends on: > ....jackson 1.9.11 (optional) > log4j-flume-ng depends on: > ....flume-ng-sdk 1.3.1 depends on: > ........avro 1.7.2 depends on: > ............jackson 1.8.8 > flume-embedded (sample) depends on: > ....flume-ng-sdk 1.3.1 depends on: > ........avro 1.7.2 depends on: > ............jackson 1.8.8 > ....flume-ng-node 1.3.1 depends on: > ........jackson 1.9.3 > > So, we already had three different versions of Jackson in the build: 1.8.8, > 1.9.3, and 1.9.11 ... yuck! > > I took the following steps: > > 1) I upgraded log4j-core's dependency from 1.9.11 to 2.2.1 without any > negative consequences. Everything compiled and all the tests passed. At this > point the dependencies were now 1.8.8, 1.9.3, and 2.2.1. > 2) I used dependency exclusions to exclude 1.8.8 and got it down to just > 1.9.3 and 2.2.1. Everything compiled and all the tests passed. > 3) I tried to eliminate 1.9.3 through a further dependency exclusion, but > log4j-flume-ng classes didn't load anymore. This indicated that Jackson is > NOT an optional dependency of log4j-flume-ng, but instead is a mandatory > dependency, which wasn't obvious the way it was set up. > 4) I kept the 1.9.3 dependency exclusion but added a mandatory 1.9.11 > /runtime/ dependency for log4j-flume-ng. Now everything compiles and all > tests pass again, and the Jackson dependencies are limited to the latest > minor.patch versions of each major version: 1.9.11 (log4j-flume-ng only, > runtime) and 2.2.1 (log4j-core only, compile). > > Ralph said below "I have no problem upgrading to 2.x so long as it works for > both the JSON configuration and Flume." It doesn't work with Flume; Flume > requires 1.x. So as a next step we can either: > > 1) Revert my changes to configuration so that it relies on Jackson 1.9.11 as > well and not on 2.2.1. > 2) Apply my earlier suggestion that we support both 1.9.11 /and/ 2.2.1 or > configuration. > 3) Stick with what we have: 1.9.11 for Flume, 2.2.1 for JSON configuration, > and no more dependency on 1.8.8. > > Nick > > On May 15, 2013, at 7:33 PM, Ralph Goers wrote: > > > I wrote the JSON support just after the ApacheCon in Vancouver, which I > > believe was in 2011. If 2.x was available then it was brand new and the > > documentation was slim. I have no problem upgrading to 2.x so long as it > > works for both the JSON configuration and Flume (I don't think Flume > > actually uses JSON but Avro probably does). Like you, I would prefer not > > to have two versions of Jackson in out build. > > > > Ralph > > > > > > On May 15, 2013, at 11:16 AM, Gary Gregory wrote: > > > >> I would only support the current version: 2.x. > >> > >> Gary > >> > >> > >> On Wed, May 15, 2013 at 2:00 PM, Nick Williams > >> <nicho...@nicholaswilliams.net> wrote: > >> Guys, > >> > >> Background: Since I'm the lead developer on a Jackson Mapper module > >> (https://github.com/FasterXML/jackson-datatype-jsr310), I'm actively > >> involved on their development mailing list. > >> > >> Jackson 1.9 is, well, old. Specifically, 1.9.0 is two years old. 1.9 is > >> the last minor version of the 1.x family. There will continue to be bug > >> fixe releases—for now—about every 4-6 months. The last patch release was > >> in January. > >> > >> Jackson 2.x is the current version with rapid release periods. 2.0 Is > >> about a year old, 2.1 was released in October and 2.2 was released last > >> month. Only major bugs will be fixed in 1.9.x. Minor bug fixes and all new > >> features will go in 2.x. > >> > >> Jackson 1.x and 2.x use different Java packages. This has both advantages > >> and disadvantages. One advantage is that frameworks and libraries, like > >> Spring Framework, can easily support both versions because they can > >> coexist on the same class path during compilation and testing. One > >> disadvantage is that if some library is using 1.x and some other library > >> is using 2.x and you create an application that depends on both libraries, > >> you'll have to pull BOTH versions of Jackson on to your class path. Ugh. > >> > >> Log4j 2 is "brand new" (it's not even released yet). Typically, I would > >> argue that new projects should not use old versions of their dependencies. > >> In Log4j 2's case, I tend to lean the same direction. It doesn't seem wise > >> to tie ourselves to Jackson 1.x so late in its life when Jackson 2.x is > >> already mature and Log4j 2 isn't even released yet. As a Java 8, Spring 4, > >> Jackson 2 user, I know I wouldn't love having to also have Jackson 1 on my > >> class path (if I were using JSON configuration). > >> > >> I would suggest that we should either support both or we should only > >> support 2.x, but only supporting 1.x feels wrong to me. > >> > >> Supporting both wouldn't be a major challenge. The way Spring does it is > >> to have two Jackson* classes and Jackson2* classes with identical APIs. > >> Depending on which version you are already using, you use the appropriate > >> class. In this case, I would approach it like this: > >> > >> - Rename JSONConfiguration to Jackson1JSONConfiguration, and (using > >> CheckStyle's import control) ensure that only this class imports Jackson > >> 1.x > >> - Create a similar class named Jackson2JSONConfiguration, and ensure that > >> only this class imports Jackson 2.x > >> - Alter JSONConfigurationFactory to detect which version is on the class > >> path and return the appropriate JSON configuration, preferring 2.x if both > >> are on the class path > >> > >> Thoughts? > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org > >> > >> > >> > >> > >> -- > >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > >> Java Persistence with Hibernate, Second Edition > >> JUnit in Action, Second Edition > >> Spring Batch in Action > >> Blog: http://garygregory.wordpress.com > >> Home: http://garygregory.com/ > >> Tweet! http://twitter.com/GaryGregory > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory
