Migration guide
Half of an EJB application's behavior lives in deployment descriptors and container semantics, not in Java. This guide shows how to extract both so a Quarkus team builds against the full contract.
By Pranav Kulkarni, Head of Language Engineering · Updated 15 Oct 2026
Technical syntax challenges
In EJB 2.x, <container-transaction> entries in ejb-jar.xml set Required, RequiresNew, Mandatory or NotSupported per method, sometimes with * wildcards. Quarkus has no EJB container, so each attribute must become an explicit @Transactional(TxType.X) on a CDI bean, and the spec has to say which method had which.
A checked application exception thrown from a CMT method leaves the transaction to commit unless the bean called ctx.setRollbackOnly(); a system exception rolls it back. Jakarta @Transactional follows similar defaults, but a port that wraps exceptions differently changes which partial updates persist.
EJB 2.x splits a bean into home, remote or local, and implementation classes, wired by JNDI names such as java:comp/env/ejb/Account. The business operations are on the remote interface; the create and finder methods on the home interface are lifecycle plumbing.
<method-permission> and <security-role-ref> entries restrict who can call each method. They are rules in their own right and map to @RolesAllowed checks in the target, but only if someone extracts them.
WebLogic and WebSphere binding files add pool sizes, timeouts and JNDI mappings. Stateful session beans keep conversation state on the server, which a stateless Quarkus REST service must replace with explicit resources or tokens.
Extraction workflow
The sequence a PYD ENTERPRISES Discovery Scan runs for this stack. Every output links back to source file and line range.
Provide source or compiled EAR, WAR and EJB JAR modules with ejb-jar.xml, application.xml, vendor descriptors and any annotations used on EJB 3.x beans.
PYD ENTERPRISES resolves each bean's interfaces, JNDI names, transaction attributes and security roles, with XML overriding annotations as the spec requires.
Lookups and injected references are resolved to concrete beans, so a remote call chain from a servlet through three session beans is one traced path.
Program slicing from each persisted field and each thrown application exception isolates validation and calculation rules, emitted as DMN tables with source links.
Remote interfaces become OpenAPI 3.1 operations annotated with transaction attribute, required roles and exception-to-status mappings.
Equivalence fixtures cover success, application exception and system exception paths and assert the persisted state after each, so the Quarkus service proves the same commit behavior.
Legacy in, specification out
Left: the Java EE / EJB construct as it sits in production. Right: the reviewed artifact your Quarkus engineers build against. PYD ENTERPRISES produces the spec and the tests; your team writes the service.
LEGACY SOURCE
1// ejb-jar.xml: TransferBean.transfer trans-attribute=Required2// ejb-jar.xml: method-permission role-name=teller, supervisor3public class TransferBean implements SessionBean {4 private SessionContext ctx;56 public void transfer(String fromId, String toId, BigDecimal amount)7 throws InsufficientFundsException, FinderException {8 AccountLocalHome home = (AccountLocalHome)9 new InitialContext().lookup("java:comp/env/ejb/Account");10 AccountLocal from = home.findByPrimaryKey(fromId);11 AccountLocal to = home.findByPrimaryKey(toId);12 if (amount.compareTo(new BigDecimal("10000.00")) > 013 && !ctx.isCallerInRole("supervisor")) {14 throw new EJBException("Approval limit exceeded");15 }16 if (from.getBalance().compareTo(amount) < 0) {17 throw new InsufficientFundsException(fromId);18 }19 from.setBalance(from.getBalance().subtract(amount));20 to.setBalance(to.getBalance().add(amount));21 }22}
EXTRACTED ARTIFACT
1openapi: 3.1.02info: { title: Funds transfer (from TransferBean), version: 1.0.0 }3paths:4 /transfers:5 post:6 operationId: createTransfer7 x-pyd-source: TransferBean.java:5-218 x-pyd-transaction: REQUIRED9 x-pyd-roles: [teller, supervisor]10 x-pyd-decision: XFER-LIMIT-0111 requestBody:12 content:13 application/json:14 schema:15 type: object16 required: [fromId, toId, amount]17 properties:18 fromId: { type: string }19 toId: { type: string }20 amount: { type: string, pattern: "^\\d+\\.\\d{2}$" }21 responses:22 "201": { description: Transfer posted }23 "403": { description: amount > 10000.00 and caller not supervisor (system exception, rollback) }24 "404": { description: FinderException, account not found }25 "422": { description: InsufficientFundsException, no state change }
Architectural best practices
In depth
Quarkus implements CDI (through ArC), Jakarta REST, Jakarta Transactions and Jakarta Persistence, but not Enterprise Beans. That is the point: you get fast startup and a small footprint by dropping the container that was silently managing transactions, pooling, security and remote invocation.
The consequence is that everything the container did must become explicit, and the only complete record of what it did is the combination of Java code and descriptors. PYD ENTERPRISES merges the two into one model per bean and exports the business operations, their transaction and security semantics and their rules as reviewed specs. It does not write Quarkus code; your engineers do, against those specs.
The transfer method has two rules and one trap. The rules: transfers over 10,000.00 need the supervisor role, and the source balance must cover the amount. The trap: the limit check throws EJBException, a system exception that rolls back and is reported to remote clients as a RemoteException, while the balance check throws a checked application exception that does not roll back. Because both checks run before any write, no partial update happens today. If a later change moves a setter above the balance check, the application exception path would commit half a transfer. The extracted spec records both exception classes and their rollback behavior so the Quarkus design makes that choice on purpose.
FAQ
Yes. Annotations such as @Stateless, @TransactionAttribute and @RolesAllowed are read alongside XML descriptors, and XML overrides are applied as the EJB specification defines.
Bytecode analysis covers structure, call graphs and descriptors. Rule extraction is more precise with source, so most teams provide source for business modules and compiled jars for libraries.
CMP and BMP entity beans are covered in the EJB entity beans to JPA and Spring Data guide, including CMR relationships and EJB QL finders.
Request a codebase scan and review extracted rules, contracts and fixtures for your own Java EE / EJB estate, inside your VPC.