Posts tagged JakartaEE (7)

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. 

🔥NoSQL Persistence on The Jakarta EE Platform With Google Firestore🔥

SQL isn't your only option! 
 
Document NoSQL databases store data as document objects, much like JSON objects. Google Firestore is a document database, a NoSQL database offering from Google’s Firebase service. You store your data in documents that are collected into collections.

This guide will introduce you to incorporating Firestore NoSQL database into your Jakarta EE application.

5 Jakarta EE (Formerly Java EE) Myths That Need To Die

The Jakarta EE Platform has come a long way since its debut as J2EE back the days of Sun Microsystems. Over the years, it has had its fair share of challenges. A natural consequence of this is that some notions about the platform arising from some of the past challenges that may have been true about past iterations have stuck. This blog post aims to dispel some of these deeply rooted misconceptions about the Jakarta EE Platform, especially after the last major release.

Payara is Part of the MicroProfile Working Group!

Payara is part of the MicroProfile Working Group! 

MicroProfile is a set of Enterprise Java APIs and technologies, designed to help with the challenge of building microservices architectures in Java. 

The MicroProfile Working Group develops these APIs in a collaborative process, and is comprised of passionate individuals, and representatives from different vendors and Java User Groups.