Created a jira ticket for this:
https://issues.apache.org/jira/browse/NIFI-12117
> On Sep 19, 2023, at 5:09 PM, Bryan Bende wrote:
>
> Yes, even if we don't expose a property and pick a very large default, it is
> going to require going through each extension one by one, since they all
> co
"Changing the default value to an unlimited number would negate the protection
that the new restriction provides.”
Yes, requesting to negate it. If a dev needs to reduce the bounds, then
provide a mechanism for this in the processors in a future Nifi release.
From:
https://github.com/FasterXM
Yes, even if we don't expose a property and pick a very large default, it
is going to require going through each extension one by one, since they all
control the creation of their own ObjectMapper.
We may be able to create a shared utility module that they could all depend
on with a factory to cre
Changing the default value to an unlimited number would negate the
protection that the new restriction provides.
It should not be necessary to make global changes, but focusing on
Processor and Controller Service references would be a good starting point
for introducing configurable sizes.
Regard
Probably worth noting that the Jackson ObjectMapper is used in lots of
places across the code base - 182 hits in GitHub on current main branch
(some of those are duplicates within classes).
So it could be a significant change to update and test all places where
it's currently used. The string leng
Defaulting maxStringLength to Integer.MAX_VALUE would be my vote. It would
work as it had previously and as expected. I do not currently see a use case
where my client would want to restrict the size of a json string…using fileSize
to route is adequate.
> On Sep 18, 2023, at 4:53 PM, Bryan Be
