Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

An opt-in or opt-out mechanism for default ProblemPostProcessors #326

Open
chberger opened this issue Nov 23, 2023 · 2 comments
Open

An opt-in or opt-out mechanism for default ProblemPostProcessors #326

chberger opened this issue Nov 23, 2023 · 2 comments

Comments

@chberger
Copy link
Contributor

Describe the solution you'd like
It would be nice if a user could opt-in or opt-out for the default ProblemPostProcessors. Currently, they are registered (by intention) somehow hard-coded in the PostProcessorsRegistry:

    public synchronized void reset() {
        processors.clear();
        register(new ProblemLogger(LoggerFactory.getLogger("http-problem")));
        register(new ProblemDefaultsProvider());
    }

In addition, in comparison to the custom PostProblemProcessors, these beans are just Pojos and no managed beans. Thus a replacement/adjustment of the functionality is not that easy. In our case we'd like to change the implementation of ProblemLogger. Instead of slf4j we'd like to use jboss-loggingand we would also log some additional fields (trace & span ids) beside the serialized http problem and context data.

Right now we use ASM to modify the bytecode to get rid of the registration. However, this approach isn't that maintainable and I would love to have a configuration option in place.

@lwitkowski wdyt?

@lwitkowski
Copy link
Collaborator

Hi @chberger, that's a good idea.

Just one hint: you can add stuff into logging via MDC, look at first config option: https://github.com/TietoEVRY/quarkus-resteasy-problem#configuration-options

@chberger
Copy link
Contributor Author

Thanks for pointing this out. I've seen that option, however then the trace and span id would be logged as part of the mdc field. I have some strict requirements to log these ids as dedicated fields with specific naming conventions.

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

No branches or pull requests

2 participants