Arjan Tijms' Weblog

A while ago we took a look at container authorization in Java EE , which we saw was taken care of by a specification called JACC . We saw that JACC offered a clear standardized hook into what's often seen as a completely opaque and container specific process, but that it also had a number of disadvantages. Furthermore we provided a partial (non-working) implementation of a JACC provider to illustrate the idea. In this part of the article we'll revisit JACC by taking a closer look at some of the mentioned disadvantages and dive a little deeper in the concept of role mapping. In part II we'll be looking at the first element of a more complete implementation of the JACC provider that was shown before. To refresh our memory, the following were the disadvantages that we previously discovered: Arcane & verbose API No portable way to see what the groups/roles are in a collection of Principals No portable way to use the container's role to group mapper No de

One of the new specs that will debut in Java EE 8 will be MVC 1.0, a second MVC framework alongside the existing MVC framework JSF. A lot has been written about this. Discussions have mostly been about the why , whether it isn't introduced too late in the game, and what the advantages (if any) above JSF exactly are. Among the advantages that were initially mentioned were the ability to have different templating engines, have better performance and the ability to be stateless. Discussions have furthermore also been about the name of this new framework. This name can be somewhat confusing. Namely, the term MVC to contrast with JSF is perhaps technically not entirely accurate, as both are MVC frameworks. The flavor of MVC intended to be implemented by MVC 1.0 is actually "action-based MVC", most well known among Java developers as "MVC the way Spring MVC implements it". The flavor of MVC that JSF implements is "Component-based MVC". Alternative term

After a poll regarding the future dependencies of OmniFaces 2.0 and two release candidates we're proud to announce that today we've finally released OmniFaces 2.0. OmniFaces 2.0 is a direct continuation of OmniFaces 1.x, but has started to build on newer dependencies. We also took the opportunity to do a little refactoring here and there (specifically noticeable in the Events class). The easiest way to use OmniFaces is via Maven by adding the following to pom.xml: <dependency> <groupId>org.omnifaces</groupId> <artifactId>omnifaces</artifactId> <version>2.0</version> </dependency> A detailed description of the biggest items of this release can be found on the blog of BalusC . One particular new feature not mentioned there is a new capability that has been added to <o:validateBean> ; class level bean validation. While JSF core and OmniFaces both have had a validateBean for some time, one thing it c

After an intense debugging session following the release of OmniFaces 2.0, we have decided to release one more release candidate; OmniFaces 2.0 RC2. For RC2 we mostly focused on TomEE 2.0 compatibility. Even though TomEE 2.0 is only available in a SNAPSHOT release, we're happy to see that it passed almost all of our tests and was able to run our showcase application just fine. The only place where it failed was with the viewParamValidationFailed page, but this appeared to be an issue in MyFaces and unrelated to TomEE itself. To repeat from the RC1 announcement: OmniFaces 2.0 is the first release that will depend on JSF 2.2 and CDI 1.1 from Java EE 7. Our Servlet dependency is now Servlet 3.0 from Java EE 6 (used to be 2.5, although we optionally used 3.0 features before). The minimal Java SE version is now Java 7. A full list of what's new and changed is available here . OmniFaces 2.0 RC2 can be tested by adding the following dependency to your pom.xml: <depende

Authentication is a topic that comes up often for web applications. The Java EE spec supports authentication for those via the Servlet and JASPIC specs, but doesn't say too much about how to authenticate for JAX-RS. Luckily JAX-RS is simply layered on top of Servlets, and one can therefore just use JASPIC's authentication modules for the Servlet Container Profile. There's thus not really a need for a separate REST profile, as there is for SOAP web services. While using the same basic technologies as authentication modules for web applications, the requirements for modules that are to be used for JAX-RS are a bit different. JAX-RS is often used to implement an API that is used by scripts. Such scripts typically do not engage into an authentication dialog with the server, i.e. it's rare for an API to redirect to a form asking for credentials, let alone asking to log-in with a social provider. An even more fundamental difference is that in web apps it's common

We are happy to announce that we have just released OmniFaces 2.0 release candidate 1. OmniFaces 2.0 is the first release that will depend on JSF 2.2 and CDI 1.1 from Java EE 7. Our Servlet dependency is now Servlet 3.0 from Java EE 6 (used to be 2.5, although we optionally used 3.0 features before). The minimal Java SE version is now Java 7. A full list of what's new and changed is available here . OmniFaces 2.0 RC1 can be tested by adding the following dependency to your pom.xml: <dependency> <groupId>org.omnifaces</groupId> <artifactId>omnifaces</artifactId> <version>2.0-RC1</version> </dependency> Alternatively the jars files can be downloaded directly . If no major bugs surface we hope to release OmniFaces 2.0 final in about one week from now. Arjan Tijms

When we normally talk about the Java EE cycle time, we talk about the time it takes between major revisions of the spec. E.g. the time between Java EE 6 and Java EE 7. While this is indeed the leading cycle time, there are two additional cycles that are of major importance: The time it takes for vendors to release an initial product that implements the new spec revision The time it takes vendors to stabilize their product (which incidentally is closely tied to the actual user adoption rate) In this article we'll take a somewhat closer look on the time it takes vendors to release their initial product. But first let's take a quick look at the time between spec releases. The following table lists the Java EE version history and the delta time between versions: Java EE delta times between releases Version Start date Release date Days since last release Days spent on spec 1.2 - 12 Dec, 1999 - - 1.3 18 Feb, 2000 24 Sep, 2001 653 days (1 year, 9 mo

In the Java EE platform programmers have a way to reference values in beans via textual expressions. These textual expressions are then compiled by the implementation (via the Expression Language, AKA EL spec ) to instances of ValueExpression . E.g. the following EL expression can be used to refer to the named bean "foo" and its property "bar": #{foo.bar} Expressions can be chains of arbitrary length, and can include method calls as well. E.g.: #{foo.bar(1).kaz.zak(test)} An important aspect of these expressions is that they are highly contextual, specifically where it concerns the top level variables. These consists of the object that starts the chain ("foo" here) and any EL variables used as method arguments ("test" here). Because of this, it's not a totally unknown requirement for wanting to resolve the expression when it's still in context in order to obtain the so-called final base and the final property/method , the las

A common task when developing Java EE applications is that of converting data. In JSF we convert objects to a string representation for rendering it inside an (HTML) response, and convert it back to an object after a postback. In JPA we convert objects from and to types known by our database, in JAX-RS we convert request parameters strings into objects etc etc. So given the pervasiveness of this task, is there any common converter type or mechanism in the Java EE platform? Unfortunately it appears such a common converter type is not there. While rather similar in nature, many specs in Java EE define their very own converter type. Below we take a look at the various converter types that are currently in use by the platform. JSF One of the earlier converter types in the Java EE platform is contributed by JSF. This converter type is able to convert from String to Object and the other way around. Because it pre-dates Java SE 5 it doesn't use a generic type parameter. While its

Over the last days several Java EE specs have published JSR proposals for their next versions. Today JSF published its proposal on the JSF mailing list, titled: Let's get started on JSF 2.3 The JSR groups improvements into 4 categories: Small scale new features Community driven improvements Platform integration Action oriented MVC support An interesting aspect is the "Community driven improvements", which means it's basically up to the community what will be done exactly. In practice this mostly boils down to issues that have been entered into the JSF issue tracker. It's remarkable how many community filed issues JSF has compared to several other Java EE specs; clearly JSF always has been a spec that's very much community driven. At ZEEF.com we're more than happy to take advantage of this opportunity and contribute whatever we can to JSF 2.3. Taking a look at this existing issue tracker we see there are quite a lot of ideas indeed. So wha

Yesterday WebLogic 12.1.3 was finally released . First of all congratulations to the team at Oracle for getting this release out of the door! :) Among the big news is that WebLogic 12.1.3 is now a mixed Java EE 6/EE 7 server by (optionally) supporting several Java EE 7 technologies like JAX-RS 2.0. Next to this there are a ton of smaller changes and fixes as well. One of those fixes concerns the standard authentication system of Java EE (JASPIC). As we saw some time back , the JASPIC implementation in WebLogic 12.1.1 and 12.1.2 wasn't entirely optimal (to WebLogic's defense, very few JASPIC implementations were at the time). One particular problem with JASPIC is that it almost can't be any different than that its TCK is rather incomplete; implementations that don't actually authenticate or which are missing the most basic functionality got certified in the past. For this purpose I have created a small set of tests that checks for the most basic capabilities. Not