On Fri, 2026-01-30 at 14:26 -0800, Ryan Schmitt wrote: > It looks like this module's API is coupled to Jackson 2.x, since the > public > method signatures refer to types like `ObjectMapper`. It's worth > noting > that Jackson 3 is already out, so in principle we'll eventually need > `httpcomponents-jackson3` (since Jackson 3's class names are all > different: > `com.fasterxml.jackson` -> `tools.jackson`) which will have to build > with > Java 17. > > If the goal of this module is to integrate the async client (i.e. > AsyncEntityProducer and the like) with Jackson, one possibility is to > decouple the two via the Reactive Streams API, which the client can > already > integrate with. Then the problem becomes "expose reactive bindings > for > Jackson:" the client gives you a `Producer<ByteBuffer>` which you > turn into > a producer of JSON tokens or DOM types or mapped objects, and all the > RxJava forces of darkness can be brought to bear on the problem. From > a > quick google search, it looks like someone took a crack at this > problem > years ago: https://github.com/kptfh/json-reactive >
I think I made a full disclaimer at the very beginning the module had been tightly coupled to Jackson 2 APIs. I made no attempts at abstracting it away behind an extra API layer. I intentionally wanted the full flexibility of Jackson to be exposed to the end user. I wanted a means of representing HTTP data streams as a stream of low level native JSON events and not just a straight JSON to Object mapping. At some point Jackson 2 will get superseded by Jackson 3, Jackson 5, Michael Jackson, or some new library entirely. We will have to deal with that (if HttpComponents are still relevant at that point) same way we had to deal with RxJava2 to RxJava3 bump. We still have a reminder of that in our project's pom.xml. Oleg > > On Fri, Jan 30, 2026 at 10:22 AM Oleg Kalnichevski <[email protected]> > wrote: > > > I just committed the initial contribution of the JSON binding > > module > > for HttpCore. > > > > This is the part of the project has been stable for years. Now, on > > top > > of that I would like to add a few improvements based on what I have > > learned while working on JSON bindings. Primarily I would like to > > add > > factory or assembly classes intended to simply wiring of common > > message > > processing pipelines for JSON messages but also for generic / > > simple > > data types. > > > > Those changes should not spill over into the client module, should > > be > > primarily core functionality focused, and should be of little > > interest > > to those who are primarily interested in the client side of things. > > > > I will be committing those changes once I feel they are ready for > > an > > alpha release. > > > > Feel free to keep an eye on what I am doing, post-commit review my > > changes, or ignore them entirely. If you find anything > > objectionable, > > please do let me know. I will back those changes out and re-submit > > them > > in a merge request. > > > > Oleg > > > > > > On Sat, 2025-12-20 at 18:22 +0100, Oleg Kalnichevski wrote: > > > Folks > > > > > > We ended up with a number of modules in core and client with a > > > single > > > developer and more are in the pipeline. > > > > > > I have been maintaining an event-driven, asynchronous JSON > > > message > > > processor for HttpComponents 5.x outside of HttpComponents > > > largely > > > for > > > two reasons: being a single maintainer and its having a hard > > > dependency > > > on an external library: > > > > > > https://github.com/ok2c/httpcomponents-jackson > > > > > > The module covers a functionality gap between the classic and the > > > async > > > i/o with regards to efficient processing of JSON messages. > > > > > > As the reasons for keeping the module outside HttpComponents seem > > > no > > > longer applicable I would be easier for me to maintain that > > > module > > > here. The module is small, has a single dependency on Jackson > > > JSON > > > bindings and is quite stable by now. > > > > > > If there are any objection please do let me know. > > > > > > Oleg > > > > > > ----------------------------------------------------------------- > > > ---- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > ------------------------------------------------------------------- > > -- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
