WebLogic to Spring Boot: the re-architecture path.

Choose Spring Boot when you want to stop depending on an application server at all. You build one executable jar, run it in a container or on a plain JVM, and release each application on its own schedule. The cost is code change: the Java EE container services must become Spring ones.

If you want the least change, look at WebLogic to Tomcat or a Jakarta EE server. For a wider view, see WebLogic migration.

Before: a stateless session bean annotated @Stateless with @TransactionAttribute(REQUIRED), injected into servlets with @EJB. After: a class annotated @Service and @Transactional, injected by constructor. The annotations are mechanical to change, and a recipe can do most of it. The review is about what the old container did without being asked.

Example. Every business method on an EJB runs in a transaction by default (REQUIRED), whether or not anyone wrote an annotation. In Spring, a method with no @Transactional runs with no transaction. If the conversion adds @Service and drops the transaction attribute on a few methods, two writes that used to commit or fail together can now half-succeed. Rollback rules also need a check: both models roll back on unchecked exceptions by default and not on checked ones, but EJB ApplicationException settings have no automatic Spring equivalent. Characterization tests on the failure paths catch both.

WebLogic realms, role mappings in weblogic.xml and security providers all have to be restated in Spring Security configuration. Spring Security 6 removed older configuration styles, so write it for the current model from the start. A mistake here is a vulnerability rather than a build error, so a named engineer reviews every authorization rule and we test with deliberately unauthorized requests.

This is the strangler approach from our eight principles: the old and new run together until the new proves itself.