Docker : Running Maven in Docker container via current user as non-root

Maven needs the user home to download artifacts to, and if the user does not exist in the image an extra user.home Java property needs to be set.

For example, to run as user 1000 mounting the host' Maven repo

$ docker run -v ~/.m2:/var/maven/.m2 -ti --rm -u 1000 -e MAVEN_CONFIG=/var/maven/.m2 maven mvn -Duser.home=/var/maven archetype:generate

Source : https://hub.docker.com/_/maven

https://stackoverflow.com/questions/52780802/run-maven-in-docker-container-via-current-user/52781822

Javascript : Object.defineProperty() add a new function property to an Object

 // For example Define the Product class -  the Constructor function 

function Product(id, name, price, expiryDate) {

   this.id = id;

   this.name = name;

   this.price = price;

   this.expiryDate = expiryDate;

  }

// Here, use Object.defineProperty to create property 

Object.defineProperty(Product, 'daysToExpire',{

    get() {

    return this.daysToExpire;

  }});

JavaScript / TypeScript: Object Writbale attribute, have more control on your properties

En JavaScript / TypeScript, chaque propriété d’un objet est liée à un descripteur (qui est lui-même un objet). 

Celui-ci donne plusieurs informations sur une propriété à l'aide la méthode Object.getOwnPropertyDescriptor(): 

• Est-elle configurable? 
• Est-elle énumérable ?
• Est-elle modifiable ? 
• Quelle est sa valeur ?
• etc

Exemple : 

const object1 = {

  property1: 42

};

const descriptor1 = Object.getOwnPropertyDescriptor(object1, 'property1');

console.log(descriptor1.configurable);

// expected output: true

console.log(descriptor1.value);

// expected output: 42

La méthode statique Object.defineProperty() permet de définir une nouvelle propriété ou de modifier une propriété existante, directement sur un objet. 

La méthode renvoie l'objet modifié.

Exemple de modification de proprieté: 

Object.defineProperty(object1, 'property1', {

  value: 42,

  writable: false

});

object1.property1 = 77;

// throws an error in strict mode

console.log(object1.property1);

Quelques cas d'usage pour les test avec Angular :

https://stackoverflow.com/questions/60296340/cannot-assign-to-var-because-it-is-a-read-only-property-in-angular-test-using/61820540#61820540

How to Handle Java 8 Dates and Time with Jackson in Spring Boot (JSR-310)

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

https://codeboje.de/jackson-java-8-datetime-handling/

How to Trace Transaction Behavior Details in Spring Boot

1. Introduction

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.

2. Problématique

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 :

• Transactions annulées : Lors de l'exécution d'un test avec @Rollback, des données peuvent être supprimées à la fin, rendant difficile la vérification de certaines assertions.
• Erreurs de commit : Dans certains cas, une transaction peut échouer sans explication claire dans les logs par défaut.
• Faible visibilité : Les logs par défaut ne fournissent souvent pas assez de détails pour comprendre les étapes exactes du cycle de vie d’une transaction.

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.

3. Solution

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 :

Étape 1 : Modifier le fichier de configuration application.properties ou application.yml

Pour activer les logs détaillés, ouvrez votre fichier application.properties (ou application.yml) et ajoutez-y la ligne suivante :

logging.level.org.springframework.test.context.transaction.TransactionContext=DEBUG

Cela configure le niveau de log pour TransactionContext à DEBUG. Pour un niveau de détail encore plus élevé, TRACE peut être utilisé :

logging.level.org.springframework.test.context.transaction.TransactionContext=TRACE

Étape 2 : Comprendre les niveaux de log

Dans cette configuration, voici ce que les différents niveaux de log apportent :

• INFO : Affiche les étapes essentielles de la gestion des transactions, comme l’ouverture et la fermeture.
• DEBUG : Affiche des informations détaillées sur le début, la fin, et les rollback éventuels des transactions.
• TRACE : Montre chaque étape de la transaction, incluant des détails sur les rollbacks et commits.

Étape 3 : Lancer vos tests et observer les logs

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 :

• Suivre chaque transaction, de sa création jusqu’à sa validation ou annulation.
• Identifier des erreurs liées aux transactions, telles que les problèmes de commit, ou comprendre pourquoi une transaction a été annulée.

4. Conclusion

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

Docker : Dockerfile COPY vs ADD, which one to use?

From Docker Doc : 

ADD or COPY

• Dockerfile reference for the ADD instruction
• Dockerfile reference for the COPY instruction

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/

Only the instructions RUN, COPY, ADD create layers. Other instructions create temporary intermediate images, and do not increase the size of the build.

Spring Security : How to get the current logged in user object from spring security?

 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