On Sat, 2026-01-31 at 15:47 -0500, Gary Gregory wrote: > 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 >
Sounds reasonable. I will rename the module name and the base package name an will force- push the changes to master. Oleg > > 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] > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
