Programming Tutorials

  Migrating to Hexagonal Architecture (Ports and Adapters) promises decoupled code and domain-centric design. However, it introduces a specific friction point for Spring Boot developers:   Transaction Management. In a traditional Layered Architecture, placing  @Transactional  on the Service layer is muscle memory. In Hexagonal, the "Service" is split into Use Cases, Input Ports, and Application Services. If you misplace the transaction boundary, you face two critical failures: the dreaded  LazyInitializationException  during DTO mapping, or worse, data corruption due to partial commits when a business operation spans multiple driven adapters. This guide defines strictly where  @Transactional  belongs in a robust Hexagonal setup, why it belongs there, and how to implement it using Java 21 and Spring Boot 3. The Root Cause: Why Boundaries Break To understand where to put the annotation, we must understand what Spring and Hibernate are doing under th...

  The migration from Spring Boot 2.7 to Spring Boot 3.0+ is not a trivial version bump; it is a paradigm shift in the Java ecosystem. The most immediate and jarring obstacle developers face is the application crashing at startup with   java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet   or   java.lang.ClassNotFoundException: javax.persistence.Entity . This error signifies that your bytecode is referencing the legacy Java EE APIs ( javax.* ), but the runtime environment (Spring Boot 3 / Jakarta EE) only provides the modern Jakarta EE APIs ( jakarta.* ). The Root Cause: The "Big Bang" Namespace Shift To understand the fix, you must understand the architecture change. When Oracle transferred Java EE to the Eclipse Foundation to become Jakarta EE, they retained the trademark rights to the  javax  namespace. Consequently, starting with  Jakarta EE 9 , all specifications were legally required to move from the  javax.*  package namespac...