-
Notifications
You must be signed in to change notification settings - Fork 14
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
Smarter collections logging #30
Comments
Nice idea... probably also applies to return values. Do you have a suggestion as to what limits to use or how to configure it? |
Actually, yeah, that's where I'm seeing it most, on return values from JAX-RS endpoints. I'm using MicroProfile Config in my apps, which is CDI-enabled and a fairly nice config system. Geronimo Config Impl is a handy implementation of MP Config. I kinda think collection size logging should be on by default... but maybe there are options for turning it on or off or setting thresholds, etc. |
MP Config is uber-cool! I hadn't thought of using it here, as everything else is configured statically in the code. Only the loggers are configured externally, and the interceptor doesn't know anything about that. Seems a bit oversized to use MP Config for only one aspect, doesn't it? Maybe extend the |
Sorry for the late reply!
Probably you're right, though, that an additional annotation could configure collections logging. The only down side is having to use it everywhere. If I could place the annotation at the package-info level, I would be satisfied with this approach. |
Logging parameters is really handy and encourages writing good
toString()
methods, but when the parameters are very large collections of these objects, logging-interceptortoString()
s each object.It would be nice to optionally log collection types and sizes instead of the string of each object in the collection.
The text was updated successfully, but these errors were encountered: