On Sat, Jan 31, 2026, 15:22 Ryan Schmitt <[email protected]> wrote:
> In that case I would suggest `httpcomponents-jackson2` as the module name. > I agree. Gary > On Fri, Jan 30, 2026 at 5:44 PM Oleg Kalnichevski <[email protected]> > wrote: > > > 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] > > > > >
