Pluggable JSON serialization #344
Conversation
|
cc @RyanBard and @azagniotov |
ae7e77f to
ed1c347
Compare
pom.xml
Outdated
| <dependency> | ||
| <groupId>com.fasterxml.jackson.core</groupId> | ||
| <artifactId>jackson-databind</artifactId> | ||
| <version>${jackson.version}</version> | ||
| <scope>compile</scope> | ||
| <optional>true</optional> |
There was a problem hiding this comment.
This does potentially break peoples' builds (if they weren't explicitly depending on jackson and were getting it transitively from jjwt); think a mention in the CHANGELOG.md makes sense?
There was a problem hiding this comment.
Yeah, most definitely still need to update the changelog before merging this PR.
The other solution that could very well happen for this PR is to break JJWT into multiple modules per #335's description and keep a jjwt artifact that is nothing more than a declaration of dependencies on jjwt-api, jjwt-impl and jjwt-jackson (for example).
This guarantees that those depending on the jjwt artifact still experience the same behavior.
That said, we don't have to do this and a changelog entry would be fine because JJWT's actual public API wont have backwards-incompatible changes. However the dependency-chain technique could be a nice-to-have that I'm sure would simplify things for people (and us answering questions on StackOverflow ;) ).
There was a problem hiding this comment.
That would be how I would do it (slf4j style rather than spring-boot style).
I mean, if I didn't have a unit test exercising the jjwt code in the project I tested with, it wouldn't have even broken the build. It just would have been a runtime failure.
There was a problem hiding this comment.
You also start to run into really weird errors when the versions of classes available don't match up.
Jackson is rough about that. If you accidentally mix different versions of the jackson libraries (usually due to complex maven hierarchies), you end up with runtime errors when it's actually used. In a past project, the dependencies were complex and 2.2 or something was mixed w/ 2.7 or so causing problems. We had unit tests that should have flushed this problem out, however, the test dependencies were different than the runtime dependencies, so you didn't find out until exercising the code in the app container.
There was a problem hiding this comment.
Yeah, I've experienced similar problems with Jackson - not fun. There's no question that the SLF4J-style is more deterministic, but people do love the spring-boot style.... Hrm...
…d org.json as the first implementations, with Jackson being the default. Added tests to retain 100% code coverage.
6459d4c to
8afca0d
Compare
Initial pluggable JSON (de)serialization support with Jackson and org.json as the first implementations. Jackson dependency is still the default, but this will no longer be necessary when #348 is resolved.
#335 Cannot be resolved until changelog and docs are updated.