Arjan Tijms' Weblog

In a previous article we took a look at an obscure Java EE application server that's only known in Korea and virtually unknown everywhere else. Korea is not the only country that has a national application server though. Japan is the other country. In fact, it has not one, but three obscure application servers. These Japanese servers, the so-called obscure 3, are so unknown outside of Japan that major news events like a Java EE 7 certification simply just does not make it out here . Those servers are the following: NEC WebOTX Hitachi Application Server Fujitsu Interstage AS In this article we're going to take a quick look at the first one of this list: NEC WebOTX. While NEC does have an international English page where a trial can be downloaded it only contains a very old version of WebOTX; 8.4, which implements Java EE 5. This file is called otx84_win32bitE.exe and is about 92MB in size. As with pretty much all of the Asian application servers, the native...

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