Jakarta EE: Less Magic, More Standard Web 🚀
Ten years ago we had a vision: make Axon Ivy projects work like standard Jakarta EE web applications. No more special integration for every new technology. Just… standard web stuff.
Reality check? Too many open questions. Class loading, migration, session handling. So we kept chipping away, step by step.
The foundation 🏗️
Two big architectural changes made everything possible:
- One webapp per application (Axon Ivy 10) — before, everything lived in a single shared webapp. Not great.
- Application versions — built on top of that, giving us clean boundaries and a webapp context per version.
These two changes aligned the runtime with how standard Jakarta EE actually works. And now they're paying off.
Goodbye JSF Managed Beans, hello CDI 👋
The biggest shift: moving from deprecated JSF Managed Beans to CDI beans.
Why does this matter?
- Managed Beans are JSF-only and deprecated
- CDI works everywhere — not just in HTML dialogs
- Standard dependency injection, standard lifecycle, standard everything
- Less custom framework code in Axon Ivy = fewer bugs
CDI is not "the new JSF bean." It's a proper application-wide dependency injection model.
Before (JSF Managed Bean)
import javax.faces.bean.ManagedBean;
import javax.faces.bean.ViewScoped;
@ManagedBean
@ViewScoped
public class CustomerBean {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
After (CDI Bean)
import jakarta.inject.Named;
import jakarta.faces.view.ViewScoped;
import java.io.Serializable;
@Named
@ViewScoped
public class CustomerBean implements Serializable {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
The EL expressions in your HTML dialogs (like #{customerBean.name}) usually stay the same. The real change is the imports and @ManagedBean → @Named.
Updated libraries 📦
With Jakarta, we updated the whole stack to current versions. Security patches, bug fixes, the works:
- Hibernate — Jakarta Persistence
- MyFaces — JSF implementation
- Tomcat — servlet engine
- Apache CXF — web services
- Jackson — JSON
- Jersey — REST
- Weld — CDI
- ...
No more carrying ancient Java EE-era dependencies. 🎉
What already got better ✅
- Removed piles of special handling code — the original frameworks do the work now
- Webapp context reloads are cleaner and more predictable
- Faster startup thanks to prebuilt Jandex indexes — bean discovery no longer needs to scan classes at boot time
The trade-off (for now): deployments reset CDI bean state and HTML dialog states. We know, we'll improve it. But the cleaner architecture is worth it.
What comes next 🔮
- Ivy Project Converter from
javax → jakarta and JSF Managed Beans → CDI beans
- Better VS Code validation — if your CDI config is broken, the whole application won't start. We need better feedback before that happens.
- Cleanup — remove obsolete workarounds like manual cache invalidations and custom managed bean management. The frameworks handle it now.
Try it out 🧪
Want to convert an existing project? Here's how:
- Install or update the latest Axon Ivy VS Code extension
- Use a dev or nightly Engine release
- Open your existing Ivy project
- Change the
ivy-project-parent version to 14.0.0-jakarta-SNAPSHOT in your Maven pom.xml
- Convert
javax → jakarta imports and @ManagedBean → @Named
- Check the Portal master...jakarta comparison for a real-world reference of the needed changes
- See how it works — if the webapp doesn't start, check your CDI bean definitions first
Automated converters are coming. For now, it's manual — but the Portal comparison gives you a solid blueprint.
If you do not want to be affected by the Jakarta changes yet, use the sprint release Engine instead.
Ten years of vision, two major architecture changes, one big library update, and a lot of deleted workaround code later — Axon Ivy projects are closer than ever to being proper Jakarta EE web applications. Not there yet, but close. And it feels good. 😎
