Arjan Tijms' Weblog

We are proud to announce that OmniFaces 2.1 release candidate 1 has been made available for testing. OmniFaces 2.1 is the second release that will depend on JSF 2.2 and CDI 1.1 from Java EE 7. Since Java EE 7 availability remains somewhat scarce, we maintain a no-frills 1.x branch for JSF 2.0 (without CDI). For this branch we've simultaneously released a release candidate as well: 1.11-RC1. A full list of what's new and changed is available here . OmniFaces 2.1 RC1 can be tested by adding the following dependency to your pom.xml: <dependency> <groupId>org.omnifaces</groupId> <artifactId>omnifaces</artifactId> <version>2.1-RC1</version> </dependency> Alternatively the jars files can be downloaded directly . For the 1.x branch the coordinates are: <dependency> <groupId>org.omnifaces</groupId> <artifactId>omnifaces</artifactId> <version>1.11-RC1</version...

In this article we take a look at the latest April 2015 beta version of IBM's Liberty server, and specifically look at how well it implements the Java EE authentication standard JASPIC. The initial version of Liberty implemented only a seemingly random assortment of Java EE APIs, but the second version that we looked at last year officially implemented the (Java EE 6) web profile. This year however the third incarnation is well on target to implement the full profile of Java EE 7. This means IBM's newer and much lighter Liberty (abbreviated WLP), will be a true alternative for the older and incredibly obese WebSphere (abbreviated WAS) where it purely concerns the Java EE standard APIs. From having by far the most heavyweight server on the market (weighing in at well over 2GB), IBM can now offer a server that's as light and small as various offerings from its competition. For this article we'll be specifically looking at how well JASPIC works on Liberty. Please ta...

It's a well known fact that in Java EE security one can specify security constraints in web.xml . It's perhaps a little lesser known fact that in full profile Java EE servers those constraints are translated by the container to instances of the Permission class. The specifications responsible for this are Servlet and JACC. This article shows a simple example of what this translation looks like. Web.xml constraints We're putting the following constraints in web.xml : <security-constraint> <web-resource-collection> <web-resource-name>Forbidden Pattern</web-resource-name> <url-pattern>/forbidden/*</url-pattern> </web-resource-collection> <auth-constraint/> </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>Protected Pattern</web-resource-name> <url-pattern>/protected/*</url-pattern> </w...

This is the third and final part of a series where we revisit JACC after taking an initial look at it last year. In the first part we mainly looked at various role mapping strategies, while the main topic of the second part was obtaining the container specific role mapper and the container specific way of how a JACC provider is deployed. In this third and final part we'll be bringing it all together and present a fully working JACC provider for a single application module (e.g. a single war). Architecture As explained before , implementing a JACC provider requires implementing three classes: PolicyConfigurationFactory PolicyConfiguration Policy Zooming into these, the following is what is more accurately required to be implemented: A factory that provides an object that collects permissions A state machine that controls the life-cyle of this permission collector Linking permissions of multiple modules and utilities Collecting and managing permissio...

For a little over 3 months (from half of November 2014 to late February 2015) we had a poll on the OmniFaces website asking what AS (Application Server) people used with OmniFaces (people could select multiple servers). The response was quite overwhelming for our little project; no less than 840 people responded , choosing a grand total of 1108 servers. The final results are as follows: Position Server Votes (Percentage) 1 JBoss (AS/EAP/WildFly) 395 (47%) 2 GlassFish 206 (24%) 3 Tomcat/Mojarra/Weld 186 (22%) 4 TomEE 85 (10%) 5 WebSphere 55 (6%) 6 WebLogic 49 (6%) 7 Tomcat/MyFaces/OWB 33 (3%) 8 Jetty/Mojarra/Weld 19 (2%) 9 Geronimo 13 (1%) 10 JEUS 11 (1%) 11 Liberty 9 (1%) 12 Jetty/MyFaces/OWB 9 (1%) 13 JOnAS 8 (0%) 14 NetWeaver 8 (0%) 15 Resin 6 (0%) 16 InforSuite 5 (0%) 17 WebOTX 4 (0%) 18 Interstage AS ...

I maintain a page on zeef.com about the upcoming Java EE 8 specification . On this page I collect all interesting links about the various sub-specs that will be updated or newly introduced in EE 8. The page is up since April last year and therefor currently has almost 10 months worth of data (at the moment 8.7k views, 5k clicks). While there still aren't any discussions and thus links available for quite a couple of specs, it does give us some early insight in what's popular. At the moment the ranking is as follows: Position Link Category 1 Java EE 8 roadmap [png] Java EE 8 overal 2 JSF MVC discussion JSF 2.3 3 Let's get started on JSF 2.3 JSF 2.3 4 Servlet 4.0 Servlet 4.0 5 Java EE 8 Takes Off! Java EE 8 overal 6 An MVC action-based framework in Java EE 8 MVC 1.0 7 JSF and MVC 1.0, a comparison in code MVC 1.0 8 Let's get started on Servlet 4.0 Servlet 4.0 9 Jav...

This is the second part of a series where we revisit JACC after taking an initial look at it last year. In the first part we somewhat rectified a few of the disadvantages that were initially discovered and looked at various role mapping strategies. In this second part we'll take an in-depth look at obtaining the container specific role mapper and the container specific way of how a JACC provider is deployed. In the next and final part we'll be bringing it all together and present a fully working JACC provider. Container specifics The way in which to obtain the role mapper and what data it exactly provides differs greatly for each container, and is something that containers don't really document either. Also, although the two system properties that need to be specified for the two JACC artifacts are standardized, it's often not at all clear how the jar file containing the JACC provider implementation classes has to be added to the container's class path. A...