Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Allow suppresion of source information in exception messages #1158

Open
jamesagnew opened this issue Dec 6, 2023 · 9 comments
Open

Allow suppresion of source information in exception messages #1158

jamesagnew opened this issue Dec 6, 2023 · 9 comments

Comments

@jamesagnew
Copy link

This is a follow-on from the discussion in #1151 .

Currently the JsonParser.Feature.INCLUDE_SOURCE_IN_LOCATION setting can be used to choose whether to include source information as a part of the location in JsonProcessingException.

When this is disabled, the message now includes messages such as:

at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 4, column: 18]

It would be nice to have configuration that just disables the source entirely from this text blurb, logs and messages don't have a reference to internal implementation details. Ideally this would result in messages more like:

at [line: 4, column: 18]
@pjfanning
Copy link
Member

pjfanning commented Dec 6, 2023

To be honest, I think we could just change this in 2.17 to leave out the Source: REDACTED (StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION disabled); if treamReadFeature.INCLUDE_SOURCE_IN_LOCATION is disabled. That is, I don't see the need to make this even more configurable.

@cowtowncoder
Copy link
Member

My worry is simply that if any references are removed, by default, developers are not even aware of possibility of including source as part of Location information. And so we are going to be hit by requests to start including source to show "where is the problem?" (esp. since older versions include it, for some sources).

Put another way: reference to StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION is very much intentional hint.

@cowtowncoder
Copy link
Member

I'd be willing to change behavior (to suppress "REDACTED" message) if there's consensus for doing so: would prefer discussion on jackson-dev (https://groups.google.com/forum/#!forum/jackson-dev) for that.

And if it were to happen that no one commented anything I'd accept that as quiet approval, given that there's +2 for proposal (and I'm on the fence).

@viniciusxyz
Copy link

@cowtowncoder I'm seeing these messages very constantly when using some annotation processors that have updated the jackson version, would it be possible to remove this warning?

If necessary, I will open a discussion thread

@jamesagnew
Copy link
Author

I'm happy to voice support if you do. This message is still super annoying.

@cowtowncoder
Copy link
Member

It's not meant as a warning but as a note. As I said, there needs to be something to indicate that Location could be added -- I am not tied to specific annoying message, of course, but some indication.
If we could come up better indication I'd consider change (for 2.19, this is visible enough to qualify as API change).

Alternatively, if anyone can figure out a proper way to configure it, I'd have no issue for merging PR to allow disabling the message. But from what I recall this is not a trivial thing to do unfortunately; and cannot rely on static singletons (needs to be on per-JsonFactory basis).

@SledgeHammer01
Copy link

Agreed. The message makes things look unprofessional imho. I had to write special code to get rid of it.

@jamesagnew
Copy link
Author

@cowtowncoder out of curiosity why can this config not rely on some static/singleton thing? I struggle to imagine a scenario where someone would want this strange message to appear some of the time but not other times. If they know enough to disable it, they surely are aware of the possibility of supplying source and don't need to be reminded in any of their log lines.

@cowtowncoder
Copy link
Member

@jamesagnew Jackson in general tries very hard to avoid static singletons for anything because it is almost always an embedded library and configuration must be contextual, bound by ObjectMapper / JsonFactory being used. So it's a pretty strong philosophical objection to having anything that overrides all usage everywhere.

Otherwise what invariably happens is some library/framework developer somewhere adds global configuration change, breaking other unrelated usage.

So this is not specific to configuration itself here.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants