Why is Jackson included in Couchbase's namespace?

I’m working with the Java client, and I want to do some BSON encoding (for append operations) and I’m unable to leverage bson4jackson because it depends on the public Jackson namespace, yet rather the dependency on Jackson is included in core-io.

So, I’m stuck with:

Why is it this way and not a traditional dependency? Any workarounds?

The intent is actually to simplify this kind of deployment. You should just bring in your own Jackson. By doing so, you’re not bound by the version and APIs we embed. This was the intent.

It does make the number of classes loaded and the memory used larger, but just barely so. It’s such a small difference that I don’t think you’d notice on most deployments.

If you have any trouble depending on a canonical Jackson dependency, let us know. That’d be a bug.

so, to clarify what you should do:

  • bring in the version of Jackson you want as a dependency to your project
  • use the plugin for BSON with it
  • since you deal with the JSON marshalling/unmarshalling yourself, skip the JsonObject abstraction, just store plain JSON strings into **RawJsonDocument**s
  • (you’ll have to specify that you want that kind of document by passing RawJsonDocument.class to get operations and any operation that you invoke with a String id rather than a Document)
1 Like

This is great to have if I need to go back and reference. I was able to leverage BinaryDocument to do what I needed.

@unhuman don’t forget to release the bufs after use on read!

1 Like

Yep. Did a bunch of reading on those; the bugs in the example provided here:

Helped me ensure that I did the correct things…
Since the bucket operations do a release(), the subsequent releases + the finally block release caused errors :slight_smile:

Bumping this up to re-engage discussion. Just got burned by things not working as expected due to a mix of Jacksons. If I have my entities annotated with “real” Jackson and then they are processed by “couchbase” Jackson, the annotations are in a different namespace and not respected.

This leads to really awful, undesirable behavior: Data loss.

I think it should be reconsidered to have this. It just opens up the opportunities for undetectable bugs.


1 Like

Hmmm can you please give us an example on how it can lead to data loss?

So, to be clear, we haven’t had any real world data loss (that I know of), but it became clear that it could easily happen when I was playing around with different serializes for my testing.

Basically what happens is, I have a forward / backward compatible class (uses the annotations @JsonAnySetter and @JsonAnyGetter).

Since these annotations are in an alternate namespace, they’re not invoked by Jackson.