It's great for beginners. Then it turns into a mess.
jib-maven-plugin's default example runs the build goal during the package phase.
The build goal will push the docker image to the remote registry, which may be too frequent to run in the package phase for some projects.
This template instead configures the jib-maven-plugin to run the following goals in the following phases:
| Phase | Goal | Goal Description |
|---|---|---|
| package | buildTar | Build docker image as tar file |
| install | dockerBuild | Build docker image and install in Docker daemon |
| @ControllerAdvice | |
| public class EmptyOptionalResponseBodyControllerAdvice implements ResponseBodyAdvice<Optional<?>> { | |
| @Override | |
| public boolean supports(MethodParameter returnType, @Nullable Class<? extends HttpMessageConverter<?>> converterType) { | |
| return Optional.class.isAssignableFrom(returnType.getParameterType()); | |
| } | |
| @Override | |
| public Optional<?> beforeBodyWrite(Optional<?> body, @Nullable MethodParameter returnType, @Nullable MediaType selectedContentType, | |
| @Nullable Class<? extends HttpMessageConverter<?>> selectedConverterType, |
A @Constraint annotation is normally mapped to ConstraintValidator(s) using the @Constraint#validatedBy annotation parameter.
This however has the limitation that the @Constraint annotation has to know about the ConstraintValidator(s) during compilation, which may not always be feasible (for example, if the annotation is used at the DTO layer, but a ConstraintValidator depends on the service layer
| enum Weekday { | |
| MONDAY = 'MONDAY', | |
| TUESDAY = 'TUESDAY', | |
| WEDNESDAY = 'WEDNESDAY', | |
| THURSDAY = 'THURSDAY', | |
| FRIDAY = 'FRIDAY', | |
| } | |
| enum Weekend { | |
| SATURDAY = 'SATURDAY', |
| @Component | |
| @Slf4j | |
| public class ErrorLoggingInterceptor implements ClientHttpRequestInterceptor { | |
| @Nonnull | |
| @Override | |
| public ClientHttpResponse intercept(@Nonnull HttpRequest request, @Nonnull byte[] body, ClientHttpRequestExecution execution) | |
| throws IOException { | |
| var response = execution.execute(request, body); | |
| var statusCode = response.getStatusCode(); |
| public List<String> getErrorMessages(BindingResult bindingResult) { | |
| return bindingResult.getAllErrors() | |
| .stream() | |
| .map(error -> { | |
| var defaultMessage = error.getDefaultMessage(); | |
| if (error instanceof FieldError) { | |
| var fieldError = (FieldError) error; | |
| return String.format("%s %s", fieldError.getField(), defaultMessage); | |
| } else { | |
| return defaultMessage; |
Module Augmentation can be used to patch type definitions in modules, e.g. in third-party libraries.
For example, @types/json-schema provides type definitions for JSON Schema, but the JSONSchema7 interface for Draft-07 does not support custom keywords. We cannot simply create a new type that extends JSONSchema7 (e.g. JSONSchema7WithExtensions) because JSONSchema7 recursively references itself. To allow custom keywords that start with x- (to be compatible with future versions of JSON Schema), we can augment the module to add an index signature to the JSONSchema7 interface globally.