Nuwana - Software Development

package com.aet.timesheets.common.security.config; import org.springframework.beans.factory.annotation. Autowired ; import org.springframework.beans.factory.annotation. Value ; import org.springframework.context.annotation. Bean ; import org.springframework.context.annotation. Configuration ; import org.springframework.security.authentication.AuthenticationManager; import org.springframework.security.config.Customizer; import org.springframework.security.config.annotation.authentication.configuration.AuthenticationConfiguration; import org.springframework.security.config.annotation.web.builders.HttpSecurity; import org.springframework.security.config.annotation.web.configuration. EnableWebSecurity ; import org.springframework.security.config.annotation.web.configurers.AbstractHttpConfigurer; import org.springframework.security.config.http.SessionCreationPolicy; import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder; import org.springframework.security.crypto.password.P...

Fixes to Overcome Circular Dependency in Authorization Flow We are building a Spring Boot microservices project with multiple services like: user-service (manages user info) merchant-service (manages merchant info) Other services...  Security Setup All services share a common library that:              Validates tokens              Loads user and  merchant  info by calling other services (user-service,  merchant -service) The Problem: Circular Calls Here’s what’s going wrong: The common library in a service (e.g., merchant-service) calls the user-service to get user info. But user-service also uses the same common library, and it needs merchant info → so it calls back the merchant-service. This creates a circular REST call between services: merchant→ user → merchant→ user...  This can lead to failures or stuck calls.   Options You Proposed   Option 1: Exclude endpoints from secu...

  @Transactional When You Use @Transactional at the Class Level: All public methods of the class are automatically transactional, as if you had added @Transactional on each method. Public method  ==> Runs within a transaction                                            Private / protected method  ==>  Not transactional (no proxy interception)                         Internal method call  ==>  Not transactional (e.g., calling one method from another within same class)  Spring AOP-based proxy  ==> Only public methods are proxied and eligible for transaction management   With Proxy (via @Transactional): Spring creates this proxy automatically when you use @Transactional. userService.updateUser();  Goes through proxy first:    ...

  Thread part 1: Thread for client handing request 01. Request → Thread Mapping When a request arrives, Spring Boot (via an embedded servlet container like Tomcat) assigns it to a thread from a thread pool (like the Tomcat thread pool).  Each thread handles one request at a time.  This thread is often called a worker thread. 02. ThreadLocal for Request-Specific Data ThreadLocal is used to store data that should be accessible throughout the request without passing it explicitly.  Spring Security and frameworks like Sleuth (for logging) use this under the hood.  However, ThreadLocal should be cleared manually or with proper filters/interceptors to avoid memory leaks in thread pools (since threads are reused). 03. ThreadLocal Automatically Not Cleared (Reasons have been explain at the end) If you use ThreadLocal, you must call .remove() after the request is done (or in a filter/interceptor). Spring Security and others manage their own cleanup. java threadLocal.remo...