Posts tagged JakartaEE (6)

Getting Started With Jakarta EE 10 - Jakarta CDI

Jakarta EE 10, the first major release of the platform since it was transferred to the Eclipse Foundation, did come with a slew of changes and updates to many of its constituent specifications. One such specification that received updates is the Jakarta Contexts and Dependency Injection specification. The specification release version for Jakarta EE 10 is Jakarta CDI 4.0, which came with major changes.

Two of such major changes are the split of the specification into a Lite and Full profiles and the change in default behaviour for an empty beans.xml file. In this blog post, we take a quick look at getting started with Jakarta CDI, in my view, the single most influential specification on the Jakarta EE Platform.

March 2023 Payara Platform Release: Payara 6 Enterprise!

A lot. Hot out of the Payara engineering furnace, we bring you the latest Payara Platform Community and Enterprise releases for the month of March 2023. Payara Platform Enterprise 6.0 gives you a production optimized and commercially supported runtime for your mission-critical projects, combining our top-rated support and 10 year software lifecycle with the very latest version of Jakarta EE.

Payara Platform Community 6.2023.3 is out with 4 improvements, 6 bug fixes and 3 component upgrades. Payara Platform Enterprise 5.49.0 also comes with 4 bug fixes, 3 component upgrades and 1 improvement.

Using UUID As Entity Primary Key In Jakarta EE 10

In prior versions of Jakarta EE, the use of UUID as entity ID or database primary key type was a vendor specific feature. So even though you could use it, you had to rely on vendor specific constructs to get the mapping right. With the release of Jakarta EE 10 however, the Jakarta Persistence specification now provides native support for using UUID as entity ID type.

The jakarta.persistence.GenerationType now has a UUID option that indicates to the persistence provider to generate and assign RFC 4122 UUID to the annotated field. The HelloEntity below shows how to use this new feature.

Intercepting REST Requests With Jakarta REST Request Filters

Oftentimes in web applications, there is the need to intercept a request from the client to resource methods. Sometimes this interception must take place even before the request is matched to a resource method. For such needs, Jakarta REST provides the jakarta.ws.rs.container.ContainerRequestFilter interface. This interface is a Jakarta REST extension that can be used to intercept requests to resource methods. 

An implementation of this interface can decide if requests should be intercepted before they’re matched to resource methods through the @PreMatching annotation. A pre-matched request filter will be invoked by the container before the request is matched to its intended resource method. 

For this blog post, let us look at two use cases for request filters. One is a situation where for security reasons, certain HTTP methods are not allowed. For example an organisation can have a security rule in its firewall that disallows HTTP PUT methods. In this case, either all methods have to be POST or request filters can be used to workaround the restriction. 

The second situation is for the custom implementation of authentication. Of course you absolutely should NOT hand-roll your own security setup unless you know in detail exactly what you are doing. You are better off using tried and tested security frameworks and services out there. But for this blog post, assuming we need to implement custom security, we can use a pre matching request filter. The following code snippet below shows a ContainerRequestFilter implementation that implements the two scenarios above.

How to prevent runtime type erasure using GenericEntity in Jakarta REST in Jakarta EE 10

Java generics is a great feature that allows you to have compile time checks for generics. However, due to historical reasons of backward compatibility, type information for generics is erased at runtime. A lot of the time this shouldn’t be of much concern. But there are a few cases where type information is needed at runtime for some kind of decision. 

One such situation is in Jakarta REST when the jakarta.ws.rs.core.Response object is used to return a generic collection of a specific type. For example the code below shows the creation and return of a Response object that has a list of HelloEntity as the return payload to the client. 

Returning Beautiful Validation Error Messages In Jakarta REST With Exception Mappers

All non-trivial enterprise applications have some sort of constraints on the data the application processes. These constraints could range from the simplest to the most complex custom built types. The default validation API on theJakarta EEPlatform, Jakarta Bean Validation has excellent out of the box support for constraining bean fields. Then with its @Valid annotation, you can trigger automatic validation of constrained objects in certain points of an application.