Categoría: spring

Desplegar docker una app Spring Boot 1.5.x desde Gradle

Utilizaremos el plugin gradle-docker para gradle.

build.gradle

plugins {
    id 'java'
    id 'org.springframework.boot' version '1.5.17.RELEASE'
    id 'com.palantir.docker' version '0.20.1'
    id 'com.palantir.docker-run' version '0.20.1'
}

...

jar {
    baseName = 'my-spring-boot-app'
    version = '1.0.0'
}

docker {
    dependsOn build
    name "my-docker-registry:5043/my-image-name"
    tags jar.version, 'latest'
    files jar.archivePath
    buildArgs(['JAR_FILE': jar.archiveName])
}

dockerRun {
    name "my-container-name"
    image "my-docker-registry:5043/my-image-name:${jar.version}"
    ports '8080:8080'
    env 'JAVA_OPTS': '-Xms128m -Xmx512m -server', 'SPRING_PROFILES_ACTIVE': 'my-spring-prifle'
    network 'my-docker-network'
    daemonize true
}

Dockerfile

FROM openjdk:8-jre-alpine
ARG JAR_FILE
COPY ${JAR_FILE} /app.jar
ENTRYPOINT exec java $JAVA_OPTS -jar /app.jar
EXPOSE 8080

Operaciones

Construir la imagen de docker

./gradlew clean docker dockerTag


REPOSITORY                              TAG     IMAGE ID            CREATED             SIZE
my-docker-registry:5043/my-image-name   latest  457475efc55d        9 minutes ago       145MB
my-docker-registry:5043/my-image-name   1.0.0   457475efc55d        9 minutes ago       145MB

Construir y ejecutar el contenedor

./gradlew dockerRun

Ver el estado del contenedor

./gradlew dockerRunStatus

> Task :dockerRunStatus
Docker container 'my-container-name' is STOPPED.

Ver el estado de la red

./gradlew dockerNetworkModeStatus

> Task :dockerNetworkModeStatus
Docker container 'my-container-name' is configured to run with 'my-docker-network' network mode.

Detener el contenedor

./gradlew dockerStop

Eliminar el contenedor

dockerRemoveContainer

Push imagen

./gradlew dockerPush

Spring Testing. Mostrar información de las peticiones

Cuando usamos MockMvc para testear controladores de Spring, es muy útil disponer del máximo de información referente a la petición realizada desde el test. Una forma muy sencilla es indicarle al “builder” que queremos que muestre en la salida del test dicha información.

import org.junit.Before;
import org.mockito.Mock;
import org.mockito.runners.MockitoJUnitRunner;
import org.springframework.test.web.servlet.MockMvc;

import static org.springframework.test.web.servlet.result.MockMvcResultHandlers.print;

@RunWith(MockitoJUnitRunner.class)
public abstract class MyTestClass {

    MockMvc mvc;

    @Mock
    MyRepository myRepository;

    @Before
    public void initialize() {

        mvc = MockMvcBuilders.standaloneSetup(new MyController(new MyService(myRepository)));
                .alwaysDo(print()) // Esta es la línea importante
                .build();
    }
}

Esto hace que para cada petición se se hace desde un test unitario via MockMvc muestre una información detallada de la misma:

MockHttpServletRequest:
      HTTP Method = GET
      Request URI = /my-request-path
       Parameters = {my-request-param=[my-request-param-value]}
          Headers = {my-header=[my-header-value]}

Handler:
             Type = com.example.MyController
           Method = public org.springframework.http.ResponseEntity<java.util.List<com.example.MyResponseClass>> com.example.MyController.myMethod(com.example.MyRequestBodyClass)

Async:
    Async started = false
     Async result = null

Resolved Exception:
             Type = null

ModelAndView:
        View name = null
             View = null
            Model = null

FlashMap:
       Attributes = null

MockHttpServletResponse:
           Status = 200
    Error message = null
          Headers = {Content-Type=[application/json;charset=UTF-8]}
     Content type = application/json;charset=UTF-8
             Body = [{"field":"value"}]
    Forwarded URL = null
   Redirected URL = null
          Cookies = []

Tener en cuenta que hasta versión 5.0 de Spring Framework no se muestra el contenido de la request tal y como se puede leer en el siguiente jira:

https://jira.spring.io/browse/SPR-14717

Mejorar la salida de los tests de una aplicación Spring Boot

Cuando hago aplicaciones con SpringBoot abruma un poco la cantidad de información que este muestra en el log cuando está activado el debug.

El tema es que el nivel de log lo suelo configurar a través del fichero application.properties pero cuando se ejecutan tests de JUnit donde no interviene Spring para nada este valor no se recoje y por defecto muestra todo a nivel DEBUG.

Añadiendo este fichero logback-test.xml en la ruta src/test/resources conseguiremos que los mensajes del framework Spring se muestren con nivel WARN mientras que los del paquete de mi aplicación (en el ejemplo: com.my.package) se muestren con el nivel más alto TRACE.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <include resource="org/springframework/boot/logging/logback/base.xml" />
    <logger name="org.springframework" level="WARN"/>
    <logger name="com.my.package level="TRACE"/>
</configuration>

De esta forma la salida (standard output) de los tests queda muchísimo más limpia y prácticamente se limita a los mensajes própios de mi aplicación.

Spring. Hacer que HttpLogginInterceptor muestre mensajes en el log con nivel DEBUG en lugar de INFO

Si usas okhttp en alugna aplicación Spring (o Java) hay una clase HttpLoggingInterceptor que nos permite, en tiempo de desarrollo, volcar toda la información acerca de las peticiones que hace el cliente http en el log de la aplicación.

Por defecto, HttpLoggingInterceptor muestra los mensajes en nivel de INFO, en mi caso, prefería que se mostrasen con nivel de debug.

@Configuration
public class HttpClientModule {
    
    private static final Logger logger = LoggerFactory.getLogger(HttpClientModule.class);

    @Bean
    public OkHttpClient okHttpClient(@Value("${debug.requests}") boolean debug) {
        OkHttpClient.Builder builder = new OkHttpClient.Builder();
        if (debug) {
            // La siguiente línea es la importante
            HttpLoggingInterceptor interceptor = new HttpLoggingInterceptor(logger::debug); 
            interceptor.setLevel(HttpLoggingInterceptor.Level.BODY);
            builder.addInterceptor(interceptor);
        }
        return builder.build();
    }
}

Spring Boot. Personalizar el json de error 404 y Swagger

En el proyecto en el que estoy trabajando ahora tenemos una API de servicios Rest hecha con Spring Boot y documentada usando Swagger. Existe una clase anotada con @RestControllerAdvice para personalizar la respuesta de error. He observado que cuando sucede un error 404 no se está ejecutando el método correspondiente por lo que, el JSON de error retornado, tiene el formato por defecto de Spring. Para que esto no suceda.

En el fichero application.properties

spring.mvc.throw-exception-if-no-handler-found=true
spring.resources.add-mappings=false

Implementar @RestControllerAdvice

@RestControllerAdvice
public class MyControllerAdvice {

    @ExceptionHandler(NoHandlerFoundException.class)
    public ResponseEntity<?> handleControllerException(HttpServletRequest request,
                                                       NoHandlerFoundException ex) {
        LOGGER.debug("handleControllerException. message: {}", ex.getMessage());
        // Return custom response entity
    }
}

Con esto ya responde con el formato de JSON que esperábamos.

Hacer funcionar Swagger UI

Al añadir la propiedad spring.resources.add-mappings esta solución vemos que deja de funciona Swagger UI. Da este error:

org.springframework.web.HttpMediaTypeNotAcceptableException: Could not find acceptable representation

El problema es que el autoconfigurador mvc de spring mapea recursos por defecto que son los que utiliza Swagger para mostrar su página web.

Finalmente copio el código del autoconfigurador pero hago que en lugar de aplicar a todas las url "/**" aplique sólo a "/swagger-ui.hml" tal y como se puede ver en el siguiente código:

@Configuration
@EnableWebMvc
public class MyWebMvcConfigurerAdapter extends WebMvcConfigurerAdapter {

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/webjars/**")
                .addResourceLocations("classpath:/META-INF/resources/webjars/");

        registry.addResourceHandler("/swagger-ui.html")
                .addResourceLocations(getStaticLocations());
    }

    private String[] getStaticLocations() {
        return new String[]{
                "/",
                "classpath:/META-INF/resources/",
                "classpath:/resources/",
                "classpath:/static/",
                "classpath:/public/"
        };
    }
}

Fuente

Diferentes configuracion de logback en función del Spring profile

Para una aplicación que estoy desarrollando, cuando arranco el profile “dev” me interesa que la salida del log sea por la cónsola. En un entorno de test (profile “test”) me interesa que almacene el log en un fichero. Es importante que el fichero de configuración se llame src/main/resources/logback-spring.xml.

Ejemplo:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
	<include resource="org/springframework/boot/logging/logback/base.xml" />
	<springProfile name="dev">
		<logger name="com.sourcerebels" level="debug" additivity="false">
			<appender-ref ref="CONSOLE" />
		</logger>
		<root level="warn">
			<appender-ref ref="CONSOLE" />
		</root>
	</springProfile>
	<springProfile name="test">
		<appender name="FILE" class="ch.qos.logback.core.FileAppender">
			<file>/path/to/log/logfile.log</file>
			<encoder>
				<pattern>%d{dd-MM-yyyy HH:mm:ss.SSS} %magenta([%thread]) %highlight(%-5level) %logger{36}.%M - %msg%n</pattern>
			</encoder>
		</appender>
		<logger name="com.sourcerebels" level="info" additivity="false">
			<appender-ref ref="FILE" />
		</logger>
		<root level="warn">
			<appender-ref ref="FILE" />
		</root>
	</springProfile>
</configuration>

Más info: Logging docs.

Spring Boot – Cifrar passwords en bbdd

Información obtenida del siguiente enlace.

@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {
    
    private static final Logger logger = LoggerFactory.getLogger(SecurityConfiguration.class);

    @Autowired
    private UserService userService;
    
    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
    
    @Bean
    public DaoAuthenticationProvider authProvider() {
        DaoAuthenticationProvider authProvider = new DaoAuthenticationProvider();
        authProvider.setUserDetailsService(userService);
        authProvider.setPasswordEncoder(passwordEncoder());
        return authProvider;
    }
    
    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        if (logger.isDebugEnabled()) {
            logger.debug("SecurityConfiguration.configure");
        }
        auth.authenticationProvider(authProvider());
    }
}

Failed to instantiate Pageable: Specified class is an interface

Al añadir los parámetros de paginación a un controlador de spring. Unos tests que estaba haciendo con MockMvc y Mockito me comenzaron a fallar con el siguiente error:

Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.data.domain.Pageable]: Specified class is an interface

La solución consiste en proporcionar una clase que resuelva los argumentos en tiempo de test (setCustomArgumentResolvers). Esta clase solo atiende al parámetro de tipo Pageable.

public class TestUtils {
    public static MockMvcBuilder prepareMockMvcForPageableArguments(Object... controllers) {
        return MockMvcBuilders.standaloneSetup(controllers)
                .setCustomArgumentResolvers(
                        new HandlerMethodArgumentResolver() {
                            @Override
                            public boolean supportsParameter(MethodParameter parameter) {
                                return parameter.getParameterType().equals(Pageable.class);
                            }

                            @Override
                            public Object resolveArgument(MethodParameter parameter,
                                    ModelAndViewContainer container,
                                    NativeWebRequest request,
                                    WebDataBinderFactory binderFactory) throws Exception {
                                return new PageRequest(0, 50);
                            }
                        });

    }
}

Para utilizarlo:

MockMvc mvc = TestUtils.prepareMockMvcForPageableArguments(controller).build();

Fuente:

https://github.com/terasolunaorg/terasoluna-tourreservation/blob/master/terasoluna-tourreservation-web/src/test/java/org/terasoluna/tourreservation/app/searchtour/SearchTourControllerTest.java

Paginación con Spring Data

A modo de recordatorio.

  • El controlador debe recibir un objeto de tipo Pageable
@GetMapping("/myentities")
public Page getMyEntities(final String userUuid, Pageable pageable) {
    return myRepository.findAllByUserUuid(userUuid, pageable);
}
  • Esto significa que a la llamada al controlador se le pueden pasar los parámetros page, limit y sort para controlar la página que queremos recuperar y el orden.
page=número de página a mostrar
limit=número de elementos a mostrar por página
sort=campo por el que se quiere ordenar
  •  Si se quiere personalizar el nombre de estos parámetros, se puede hacer modificando las siguientes propiedades en el fichero application.properties.
spring.data.rest.page-param-name=page
spring.data.rest.limit-param-name=limit
spring.data.rest.sort-param-name=sort
  • El repositorio tiene que extender el interfaz de Spring PagingAndSortingRepository. JpaRepository ya extiende de este.
  • El método findXX del repositorio debe devolver un objeto de tipo Page y recibir un parámetro de tipo Pageable.
@Repository
public interface MyRepository extends JpaRepository&lt;MyEntity, Long&gt; {
    public Page findAllByUserUuid(String userUuid, Pageable pageable);
}

Referencias

https://docs.spring.io/spring-data/rest/docs/1.1.x/reference/html/paging-chapter.html

Saludos

Ocultar método soportado por endpoint de terceros. Spring y Swagger.

A veces, queremos ocultar que uno de los métodos soportados por un endpoint que no controlamos no aparezca en Swagger.

No he visto que exista ninguna función para hacer esto.

Este es el Predicate que he implementado.

import org.springframework.core.annotation.AnnotationUtils;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;

import com.google.common.base.Predicate;

import springfox.documentation.RequestHandler;

public class IsRequestMethodPredicate implements Predicate<RequestHandler> {

	private final String path;
	private final RequestMethod method;

	public IsRequestMethodPredicate(String path, RequestMethod method) {
		this.path = path;
		this.method = method;
	}

	public static IsRequestMethodPredicate isRequestMethod(String path, RequestMethod method) {
		return new IsRequestMethodPredicate(path, method);
	}

	public static Predicate<RequestHandler> isNotRequestMethod(String path, RequestMethod method) {
		return not(isRequestMethod(path, method));
	}

	@Override
	public boolean apply(RequestHandler input) {
		RequestMapping mapping = AnnotationUtils
				.findAnnotation(input.getHandlerMethod().getMethod(), RequestMapping.class);
		if (mapping != null && mapping.path().length > 0) {
			return hasPath(mapping, path) && hasMethod(mapping, method);
		}
		return false;
	}

	private static boolean hasPath(RequestMapping mapping, String path) {
		for (String mappingPath : mapping.path()) {
			if (mappingPath != null && mappingPath.equals(path)) {
				return true;
			}
		}
		return false;
	}

	private static boolean hasMethod(RequestMapping mapping, RequestMethod method) {
		for (RequestMethod mappingMethod : mapping.method()) {
			if (mappingMethod == method) {
				return true;
			}
		}
		return false;
	}
}

Para utilizarlo:

import static IsRequestMethodPredicate.isNotRequestMethod;

@Bean
public Docket api() {
	return new Docket(DocumentationType.SWAGGER_2)
			.select()
			.apis(isNotRequestMethod("/some/third/party/endpoint", RequestMethod.GET))
			.paths(paths())
			.build();
}