Arjan Tijms' Weblog

Historically Java EE servers were known for being monolithic and heavyweight. Over the years this has improved tremendously with many free, open source and lightweight solutions available, such as GlassFish, TomEE, Resin and JBoss. Even the grandfather of the modern Application Server, Bea's WebLogic (now Oracle's) has severely slimmed down . One "heavyweight beast" remained though; IBM's WebSphere. It's perhaps an understatement to say WebSphere is not universally liked by developers . A 2GB download size that happens via a proprietary installer (which is 100MB), which doesn't cleanly work on all possible Linux flavors and doesn't work at all on OS X, which needs another 200MB orso just to create a "profile" after the 2GB download which came after the 100MB installer, takes ages to start and can't be started in any of the popular IDEs (like Eclipse, NetBeans or IntelliJ) are all things that don't really fly with the average dev...

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...