Jackson’s ObjectMapper is able to deserialize arbitrary objects and classes, and that is a major attack surface. We should be conservative in which configurations we allow, and should only allow configurations that cannot possibly access those capabilities of ObjectMapper.
> On Mar 27, 2026, at 1:39 AM, Danylo Naumenko via dev <[email protected]> > wrote: > > Created CALCITE-7455 <https://issues.apache.org/jira/browse/CALCITE-7455>. > Please feel free to share comments/suggestions. > > Thank you, > Danylo > > On Thu, 26 Mar 2026 at 17:59, Mihai Budiu <[email protected]> wrote: > >> I personally see no downside to your proposal. You should start by filing >> a JIRA issue and asking for comments. >> >> Mihai >> ------------------------------ >> *From:* Danylo Naumenko via dev <[email protected]> >> *Sent:* Thursday, March 26, 2026 1:14 AM >> *To:* [email protected] <[email protected]> >> *Cc:* Danylo Naumenko <[email protected]> >> *Subject:* [PROPOSAL] Make ObjectMapper configurable in JSON functions >> >> Hi all, >> >> JsonFunctions currently uses a hardcoded JacksonJsonProvider with the >> default ObjectMapper, so any Jackson module not registered by default is >> unavailable. For example, passing a Java object with Optional fields to >> JSON_OBJECT fails since serialization of Optional fields is not enabled by >> default. Registering Jdk8Module on the ObjectMapper fixes this, but it >> looks like there's no way to do that today. >> >> Looking at this more generally is there currently a way to configure >> a custom ObjectMapper? If not, would it make sense to allow configuring the >> ObjectMapper used by JSON functions? >> >> If the proposal makes sense, would you accept a contribution to enable >> this? If so, do you have any preference/guidance on how the solution should >> look like? >> >> Best regards, >> Danylo >>
