WebLogic to Tomcat
WebLogic to Tomcat: what Tomcat lacks and what replaces it.
Tomcat is a servlet container, not a full Java EE server. Moving to it is a matter of listing what WebLogic gave you and supplying each piece.
The short answer
Tomcat implements the servlet, JSP and WebSocket specifications, not the full Java EE or Jakarta EE platform. A WebLogic to Tomcat migration means replacing what Tomcat lacks: EJBs, JMS, JTA transactions and server-managed security. Typical replacements are Spring beans, an external broker, a transaction library and container authentication.
Decision
Is Tomcat the right target for a WebLogic application?
Tomcat fits web applications that mostly use servlets, JSP, JDBC and Spring. It is a poor fit if the code leans on stateful EJBs, container-managed JTA across several resources, or JMS provided by the server, because you will rebuild each of those yourself.
If most of those are present, compare it with moving to Spring Boot, which embeds Tomcat but gives you the Spring equivalents. See WebLogic to Spring Boot. For the wider plan, see WebLogic migration.
The gap list
What does Tomcat not include that WebLogic does?
Check each row against your code. Replacements shown are common choices, not the only ones.
| WebLogic provides | Tomcat | Replacement |
|---|---|---|
| EJB container (session beans, MDBs) | Not included | Spring beans and message listeners, or Apache TomEE if you want EJB kept |
| JMS provider | Not included | External broker such as ActiveMQ or RabbitMQ, through Spring JMS or AMQP |
| JTA transaction manager | Not included | Spring transaction management, or Narayana or Atomikos for XA across resources |
| Server-managed JPA persistence | Not included | Hibernate configured by the application, usually through Spring |
| CDI | Not included | Weld added as a library, or Spring dependency injection |
| JAX-RS and JAX-WS | Not included | Jersey or RESTEasy, CXF for SOAP |
| Work managers | Executors only | Thread pools tuned to match old limits |
| JNDI data sources | Supported as resources | Define in context.xml or in application properties |
| Clustering and session replication | Basic support | Stateless design or an external session store such as Redis |
| Security realms | Realms exist, different model | Tomcat realm, or Spring Security with the same identity provider |
Worked example
How do weblogic.xml and JNDI settings convert?
Take a typical web application. weblogic.xml sets a context root, a resource reference that maps a logical name to a JNDI data source, and a security role mapping. Tomcat reads the standard web.xml and context.xml, so the vendor file goes away and each setting moves.
| In weblogic.xml or the console | In Tomcat |
|---|---|
| context-root | The WAR file name, or a Context element path |
| resource-description mapping jdbc/AppDS | A Resource element in context.xml, with the driver, URL and pool settings |
| security-role-assignment to a group | A role in web.xml and a realm that maps the group name |
| container-descriptor prefer-web-inf-classes | Not needed. Tomcat already loads the web app's own classes first |
| JMS connection factory in the console | Broker client library, with connection settings in properties |
Version trap
Which Tomcat version, and why does the namespace matter?
Tomcat 9 implements Servlet 4.0 with the javax namespace. Tomcat 10 and later use the jakarta namespace. An application built for WebLogic 12c is almost certainly javax. If you pick Tomcat 10.1 you must also convert the code and every library that touches servlet or persistence APIs. If you pick Tomcat 9 you can defer that work, but Tomcat 9 is a stepping stone, not a destination.
Most teams do the namespace move once, as part of the migration, with a recipe and a dependency check. See javax to jakarta migration.
Method
What order does the migration run in?
- 1
Inventory
Scan for EJB annotations, JMS use, JNDI lookups, weblogic.* imports and descriptors. This list is the project.
- 2
Characterization tests
Pin current behavior before anything moves, including transaction and error paths.
- 3
Replace one gap at a time
AI-assisted tools and recipes do the mechanical rewrite. Engineers review each diff.
- 4
Run in parallel
Stand up Tomcat beside WebLogic and compare behavior, then shift traffic in phases.
- 5
Cut over with a way back
Keep the old path available until the new one has run clean through a full business cycle.
Code
What happens to code that imports weblogic.* classes?
Search for imports under weblogic.*. Each one is a hard dependency on the vendor, such as the weblogic.jndi context factory, T3 protocol clients or work manager APIs. They will not compile on Tomcat. Most have a standard or Spring equivalent. A few, especially T3-based remote calls between applications, need a design decision, because the caller must now speak HTTP or messaging.
After
Who supports Tomcat after the move?
Open-source Tomcat has no vendor phone number, so the question matters. AceMQ supports Tomcat 24/7, and the same team that does the migration can run it. See what we support after migration.
After go-live
Keep it running after cutover.
For web applications that use servlets, JSP, JDBC and Spring, yes. If the code uses EJBs, server-provided JMS or distributed transactions, you must supply those separately or use a fuller server or Spring Boot.
Tomcat has no EJB container, JMS provider, JTA transaction manager, CDI or JAX-RS. Each needs a library or an external service.
Only if you choose Tomcat 10 or later. Tomcat 9 still uses javax. Most teams move to jakarta during the migration so they land on a supported version.
Move the context root, resource references and role mappings into the WAR name, context.xml and web.xml. Settings with no standard equivalent become application properties or code.
Run an external broker such as ActiveMQ or RabbitMQ and connect through Spring JMS or AMQP. Check transaction semantics and message ordering carefully, since they differ.
TomEE is Tomcat with the Java EE and Jakarta EE APIs added, so EJB, JPA and JMS keep working. It reduces code change, at the cost of a smaller community than Spring.
Know the cost before anything moves.
A fixed-price assessment gives you the inventory, the risk score and a phased plan. Scope and cost are fixed before the migration starts.
Book a Fixed-Price AssessmentGet in touch
Talk to a modernization engineer
Tell us what you run today. An engineer, not a sales script, replies within one business day.