When you use Spring Boot, you can add the following line to the application.properties file:
spring.jackson.serialization.write-dates-as-timestamps=false
Spring Boot enables the configuration of the default ObjectMapper with properties under the spring.jackson prefix. Read the jackson section in the Spring Boot docs for more info on this.
more details :
https://www.baeldung.com/spring-boot-customize-jackson-objectmapper
Dans le développement d'applications avec Spring, les tests unitaires et d'intégration jouent un rôle central pour garantir la fiabilité et la stabilité du code. Cependant, tester du code qui s'exécute dans un contexte transactionnel peut devenir complexe, notamment lorsqu’on souhaite comprendre pourquoi certaines transactions échouent ou se comportent de manière inattendue. Spring fournit une API puissante pour la gestion des transactions, mais lors des tests, des erreurs subtiles peuvent survenir et il devient nécessaire de traquer la gestion des transactions.
Les transactions gérées par Spring, surtout lorsqu’elles sont imbriquées dans des couches complexes, peuvent parfois entraîner des comportements inattendus lors des tests. Par exemple :
@Rollback, des données peuvent être supprimées à la fin, rendant difficile la vérification de certaines assertions.Pour résoudre ces problèmes, configurer les logs de Spring spécifiquement pour les transactions permet de capturer plus de détails et d'obtenir une vue plus fine des opérations.
Pour diagnostiquer les transactions dans vos tests, il est utile de configurer un niveau de log approprié pour le contexte transactionnel de Spring. Voici comment faire :
application.properties ou application.ymlPour activer les logs détaillés, ouvrez votre fichier application.properties (ou application.yml) et ajoutez-y la ligne suivante :
Cela configure le niveau de log pour TransactionContext à DEBUG. Pour un niveau de détail encore plus élevé, TRACE peut être utilisé :
Dans cette configuration, voici ce que les différents niveaux de log apportent :
En configurant le niveau à DEBUG ou TRACE, exécutez vos tests. Vous verrez des logs plus détaillés relatifs aux transactions, vous permettant de :
Configurer les logs pour le contexte transactionnel dans Spring permet de mieux comprendre les opérations de transaction dans vos tests et d’identifier rapidement les problèmes liés à leur gestion. En adaptant le niveau de verbosité de log pour TransactionContext, vous pouvez obtenir une vue détaillée des étapes de chaque transaction, facilitant ainsi le débogage et le suivi des tests. Cette pratique est particulièrement utile dans des environnements de tests complexes où les transactions jouent un rôle important.
To log transaction details in a Spring Boot application simply add the following settings in application.properties:
logging.level.org.springframework.transaction.interceptor=TRACE
From Docker Doc :
Although ADD and COPY are functionally similar, generally speaking, COPY is preferred. That’s because it’s more transparent than ADD. COPY only supports the basic copying of local files into the container, while ADD has some features (like local-only tar extraction and remote URL support) that are not immediately obvious. Consequently, the best use for ADD is local tar file auto-extraction into the image, as in ADD rootfs.tar.xz /.
If you have multiple Dockerfile steps that use different files from your context, COPY them individually, rather than all at once. This ensures that each step’s build cache is only invalidated (forcing the step to be re-run) if the specifically required files change.
For example:
COPY requirements.txt /tmp/
RUN pip install --requirement /tmp/requirements.txt
COPY . /tmp/
Results in fewer cache invalidations for the RUN step, than if you put the COPY . /tmp/ before it.
Because image size matters, using ADD to fetch packages from remote URLs is strongly discouraged; you should use curl or wget instead. That way you can delete the files you no longer need after they’ve been extracted and you don’t have to add another layer in your image. For example, you should avoid doing things like:
ADD https://example.com/big.tar.xz /usr/src/things/
RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things
RUN make -C /usr/src/things all
And instead, do something like:
RUN mkdir -p /usr/src/things \
&& curl -SL https://example.com/big.tar.xz \
| tar -xJC /usr/src/things \
&& make -C /usr/src/things all
For other items (files, directories) that do not require ADD’s tar auto-extraction capability, you should always use COPY.
Source : https://docs.docker.com/develop/develop-images/dockerfile_best-practices/
RUN, COPY, ADD create layers. Other instructions create temporary intermediate images, and do not increase the size of the build.Since version 5.2 you can use CurrentSecurityContext annotation to get the current user authentication:
@GetMapping("/authentication")
public Object authentication(@CurrentSecurityContext(expression="authentication")
Authentication authentication) {
return authentication.getDetails();
}
or even:
@GetMapping("/hello")
public String hello(@CurrentSecurityContext(expression="authentication.name")
String username) {
return "Hello, " + username + "!";
}https://stackoverflow.com/questions/32052076/how-to-get-the-current-logged-in-user-object-from-spring-security