Arjan Tijms' Weblog

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