This small project adds a grpc ServerInterceptor that does several things (grpc server interceptors can add behavior to all grpc services, in a transparent way that does not require any change to the grpc service code)
- logs the request, the response messages and http headers of a grpc request with log4j at info log level. By default all grpc method calls are traced, however you can optionally limit the set of traced classes and methods by means of an optional configuration file that looks like this To activate this configuration file, set spring property spring-utils.log-definition to the log file name, the file must be in the resource path. This code relieves you of the duty to log the request and response objects for each and every grpc method.
- catch unhandled exceptions and pass the server stack trace to the client as part of the exception message. This makes it a bit easier to track problems at the client site, by looking at the error that is available at the client side. This also relieves the grpc service code of the duty to catch all java exceptions for each and every grpc method. Note that this is nice for internal GRPC services, these do not talk to the outside, and do not have to worry about leaking any details.
This helps to reduce some boiler plate code, it helps to these step, which would otherwise have had to be duplicated for each grpc entry point, and it helps to handle these aspects by a common mechanism.
When working with spring, one is often challenged to find the correct set of dependencies, luckily we have the grpc-spring-boot-starter dependency matrix in this case.
Also nowadays one should use maven central repository, jcentral is no longer updated (see announcement )