Arjan Tijms' Weblog

We're pleased to announce that the release candidate of OmniFaces 1.5 is now available for testing. The following items are new for this release: Decode UIComponent children in <o:param> when no value attribute is specified (so that you can specify JSF/HTML code as outputFormat parameter) Allow endusers to specify custom passthrough attributes for Html5RenderKit Added new includeRequestParams attribute to <o:form> <o:messages> which extends <h:messages> with support for multiple client IDs in for attribute, ability to disable HTML escaping and ability to perform markupless rendering like <ui:repeat> Faces#includeCompositeComponent() to programmatically include a composite component in given parent component Add list based alternatives for the converters that automatically convert based on select items Message interpolator for Bean Validation that allows a component's label to be inserted in the middle of ...

Java EE 7 comes with a lot of improvements in many areas. Things like JSF 2.2 , CDI 1.1, JMS 2.0 and JAX-RS 2.0 have all been massively improved. However, not all specs have seen a significant revision. A number of them like JSP 2.1 and EJB 3.1 only had a minor revision, called a maintenance release. In this post we'll take a look at the changes that were done for the standardized authentication support in Java EE: JASPIC 1.1 (JSR 196). The second maintenance release of JASPIC, called Maintenance Release B officially has seen its version bumped from 1.0 to 1.1. It's sometimes confusing, but a small maintenance release can have the same version increment as a significant revision. E.g. JSF 2.1 was a small maintenance release of its prior version 2.0, but EJB 3.1 was a significant revision of its prior version 3.0. On to the changes in JASPIC 1.1: Standardized application context identifier (AppContextID) for Servlet Profile One of the big hurdles when trying to ...

For some time now there's a trend going on to simplify URLs used on the web. Increasingly the trend is to remove technical clutter from URLs and make them cleaner and friendlier for humans to remember. E.g. from something like http://www4.campaign.myorgananization.com/dlt/cmp/~foobar/camp-2013/E3483A78H.jspx we went to: myorgananization.com/sale2013 The protocol, "http://", is mostly skipped when printing URLs for humans to type over nowadays since browsers simply default to it. The elaborate subdomains, specifically the "www1", "www2", "wwwN" nonsense, is mostly handled internally by load balancers these days, etc. E.g. I photographed the following from an ad that was displayed on Rembrandtplein, Amsterdam: The extension One specific technical part of the URL that can also be shaved off is the extension (".jspx" in the example above), and this will be the topic of this article. Technically, an extension can have ...

Basic access authentication is a crude mechanism to authenticate that's part of the HTTP standard. It allows both an agent to send username/password credentials and a server to request the agent to authenticate itself. This happens in a simple but standardized way. The mechanism can be easily implemented using Java EE's JASPIC and a sprinkle of utility code from the experimental OmniSecurity project (which is currently being discussed as one of the possible options to simplify security in Java EE 8). A basic implementation looks as follows: public class BasicAuthModule extends HttpServerAuthModule { @Override public AuthStatus validateHttpRequest(HttpServletRequest request, HttpServletResponse response, HttpMsgContext httpMsgContext) throws AuthException { String[] credentials = getCredentials(request); if (!isEmpty(credentials)) { UsernamePasswordIdentityStore identityStore = getReferenceOrNull(UsernamePa...

Undertow's native security system has an incredible useful feature that's painfully missing in the security system of Java EE; authentication events . While Java EE applications could directly use the Undertow events, it's not directly clear how to do this. Furthermore having Undertow specific dependencies sprinkled throughout the code of an otherwise general Java EE application is perhaps not entirely optimal. The following code shows how the Undertow dependencies can be centralized to a single drop-in jar, by creating an Undertow extension (handler) that bridges the native Undertow events to standard CDI ones. Upon adding such jar to a Java EE application, the application code only has to know about general CDI events. First create the handler itself: import io.undertow.security.api.NotificationReceiver; import io.undertow.security.api.SecurityNotification; import io.undertow.server.HttpHandler; import io.undertow.server.HttpServerExchange; import javax.enterpris...

This article takes a look at the state of security support in Java EE 6, with a focus on applications that wish to do their own authentication and the usage of the JASPI/JASPIC/JSR 196 API. Update: the further reading section has been moved to my ZEEF page about JASPIC . This contains links to articles, background, questions and answers, and more.   Declarative security is easy In Java EE it has always been relatively straightforward to specify to which resources security constraints should be applied. For web resources (Servlets, JSP pages, etc) there is the <security-constraint> element in web.xml, while for EJB beans there's the @RolesAllowed annotation. Via this so called 'declarative security' the programmer can specify that only a user having the given roles is allowed access to the protected web resource, or may invoke methods on the protected bean. The declarative model has a programmatic counterpart via methods like HttpServletRequest#isUserInR...

CDI has the well known concept of producers. Simply put a producer is a kind of general factory method for some type. It's defined by annotating a method with @Produces . An alternative "factory" for a type is simply a class itself; a class is a factory of objects of its own type. In CDI both these factories are represented by the Bean type . The name may be somewhat confusing, but a Bean in CDI is thus not directly a bean itself but a type used to create instances (aka a factory). An interesting aspect of CDI is that those Bean instances are not just internally created by CDI after encountering class definitions and producer methods, but can be added manually by user code as well. Via this mechanism we can thus dynamically register factories, or in CDI terms producers. This can be handy in a variety of cases, for instance when a lot of similar producer methods would have to be defined statically, or when generic producers are needed. Unfortunately, generics are not p...