The security before Java EE 8 / Jakarta EE 8 used to be a bit complicated and confusing. Every specification provided its own way to retrieve information about the logged-in user. The situation greatly improved with the introduction of the Security API that provides a unified way to do that – simply inject the SecurityContext CDI bean.(more…)
Jakarta REST (JAX-RS) defines it’s own dependency injection using the
@Context annotation. REST resources also support
CDI injection if you enable CDI on the REST resource class (e.g. using a bean-defining annotation like
But injection doesn’t work out of the box on JAX-RS sub-resources. How to create sub-resources so that both injection mechanisms work also in sub-resources? I’ll show you, it’s very easy.(more…)
Since version 9, Java has new features every 6 months and it’s very hard to keep track of these new changes. Most of the information on the internet describes changes between the last 2 Java versions. However, if you’re in a similar situation as me, you’re not using the last Java version but a version several releases older.
Then it’s useful to know which new features were added since the version you use now, or between the versions that you use now and the one you want to start using next. Therefore I’ve compiled a table with all new features added since Java 8 for each new Java version.(more…)
Recently, we had a discussion how to create a standalone Jakarta Batch test kit (TCK). For most of the committers, it’s pretty natural to use Arquillian to abstracts tests away from how they are executed on an implementation. But Romain proposed an intriguing idea to use plain JUnit5 that got me thinking. And it didn’t stop with thinking. After a few hours of hacking, I’m now able to present a proof of concept and suggest how we could use plain JUnit5 for the TCK and also how containers can be integrated with it using good old Arquillian to avoid reinventing the wheel.(more…)
Services can often be optimized with asynchronous processing even without changing their behavior towards the outside world. The reason why some services aren’t efficient is that they need to wait for other services to provide a result to continue further. Let’s look how to call external REST services without waiting for them and also do multiple parallel calls independently and combine their results later with a reactive pipeline in Java EE 8.(more…)
A singleton pattern is probably the simplest well-known design pattern, but still people often implement it incorrectly in Java.(more…)
Java EE 7 is around for a few years already, and provides several very useful and long-awaited features, like entity graphs and better support for stored procedures and results mapping. For an overview, have a look at Thorben Janssen’s blog post. The query capabilities were also enhanced, with 3 additional keywords. All of them are available in both JPQL and Criteria API:
- ON keyword to specify conditions for JOINs
- FUNCTION to call arbitrary database function
- TREAT to downcast entities to their specific type
In this post, I’ll focus on the first of them – the ON keyword in JOINs.(more…)
This post summarizes what needs to be done in order to use Facelets instead of default JSP as a view technology for MVC framework.
Although MVC is a fresh new framework, the default view technology used in most examples – JSP – is rather old and sometimes cumbersome. On the other hand, the older brother JSF already builds on more modern and flexible Facelets.
Fortunately, MVC framework has been designed to support many alternative view technologies out of the box, including Facelets.(more…)
JPA provides essentially 2 types of locking mechanisms to help synchronize access to entities. Both mechanisms prevent a scenario, where 2 transactions overwrite data of each other without knowing it.
By entity locking, we typically want to prevent following scenario with 2 parallel transactions:
- Adam’s transaction reads data X
- Barbara’s transaction reads data X
- Adam’s transaction modifies data X, and changes it to XA
- Adam’s transaction writes data XA
- Barbara’s transaction modifies data X and changes it to XB
- Barbara’s transaction writes data XB
As a result, changes done by Adam are completely gone and overwritten by Barbara without her even noticing. A scenario like this is sometimes called dirty-read. Obviously, a desired result is that Adam writes XA, and Barbara is forced to review XA changes before writing XB.