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

Smarter collections logging #30

Open
derekm opened this issue Jan 26, 2018 · 4 comments
Open

Smarter collections logging #30

derekm opened this issue Jan 26, 2018 · 4 comments
Milestone

Comments

@derekm
Copy link

derekm commented Jan 26, 2018

Logging parameters is really handy and encourages writing good toString() methods, but when the parameters are very large collections of these objects, logging-interceptor toString()s each object.

It would be nice to optionally log collection types and sizes instead of the string of each object in the collection.

@t1
Copy link
Owner

t1 commented Feb 1, 2018

Nice idea... probably also applies to return values.

Do you have a suggestion as to what limits to use or how to configure it?

@t1 t1 added the enhancement label Feb 1, 2018
@t1 t1 added this to the 3.3.0 milestone Feb 1, 2018
@derekm
Copy link
Author

derekm commented Feb 1, 2018

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.

@t1
Copy link
Owner

t1 commented Feb 1, 2018

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 @DontLog annotation: @DontLog(moreThan=10). What do you think?

@derekm
Copy link
Author

derekm commented Feb 7, 2018

Sorry for the late reply!

@DontLog seems like a little bit of a mismatch, since I still want logging, I just want less logging: name & count (variable name or type name [type name might be hard given generics erasure, unless you get anonymous null extensions that prevent erasure]).

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.

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

No branches or pull requests

2 participants