Monday, July 4, 2016

Are you also seeing below error when trying to integrate Tomcat 8.5.x or TomEE 7.x using Tomcat v8.0 Server plugin in Eclipse?

For searchbots, the error says The Apache Tomcat installation at this directory is version 8.5.3. A Tomcat 8.0 installation is expected. This error even occurs in the current Eclipse Neon release. Perhaps they'll fix it in Neon SR1 by adding a new Tomcat v8.5 Server plugin. But for now and for older versions a workaround is needed.

The Eclipse built-in Tomcat server plugin basically detects the server version based on server.info property of org/apache/catalina/util/ServerInfo.properties file of Tomcat's /lib/catalina.jar file which looks like below in case of Tomcat 8.5.3:

The same procedure applies to TomEE 7.x which is based on Tomcat 8.5.x.

The difference between Tomcat 8.0 and 8.5 is the integration of Jaspic which is the first step towards standardizing Java EE authentication as part of JSR375. You probably already know that the ways to configure Java EE container managed authentication are totally scattered across different servers, making third party libraries such as Shiro and Spring Security more attractive. Each server needed its own way of configuring "realms" or "identity stores" to manage the database of users, passwords and roles. This will with JSR375 be unified using annotations and CDI provided via standard javax.security.* API. See also a.o. the question Java EE authentication: how to capture login event?

Friday, July 1, 2016

This version has relatively few new additions, only one brand new tag <o:url> which revives good 'ol JSTL <c:url> for Facelets, and a few utility methods/functions. There are several enhancements and bugfixes in existing stuff, such as the @Param finally supporting injecting multi-valued parameters such as foo=bar1&foo=bar2 into a String[] or List<String> and injecting into primitive type fields. Those few utility methods and enhancements must further simplify logging of JSF (ajax) actions, exceptions and JavaScript errors.

For users who don't want to use CDI, there's the CDI-less 1.14 with all 2.4 enhancements and fixes (but no brand new 2.x additions nor the o:url!).

Good ol' JSTL <c:url> revived

Sometimes there's need to access and/or print the current request URL "plain vanilla" in a JSF page. Common use cases are to prepopulate a ?from= request parameter for the login form so it can figure out where to redirect back after a successful login, and filling the HTML5 link relations referring the current or another page on the same site. Previously, this could to some extent (no control over domains) be done with JSTL ><c:url> which was removed in Facelets.

This has now been revived in OmniFaces 2.4 as <o:url> and even further enhanced. It supports setting the (relative) domain via domain attribute and it supports the same includeViewParams, includeRequestParams and useRequestURI attributes as <o:form>. The <o:url> also supports the var attribute allowing to set the value as an EL variable which can in turn be used in an EL expression elsewhere in the page.

Conversion and validation is also supported on multi-valued parameters like as already supported on single-valued parameters. On multi-valued parameters, JSF native conversion and validation will run on each submitted value. Bean Validation, if any, will however be performed on the entire List or array property and not on each individual item.

Furthermore, the @Param now also supports injecting into a primitive field. Previously this wasn't possible because CDI would attempt to inject an empty value as null into the field, which would only throw an exception (no autoboxing magic there in reflection). The @Param will now automatically take care about injecting the right default value of the primitive field in case the value is absent or empty.

Logging made easier

OmniFaces 2.4 comes with several utilities and enhancements which should further simplify logging of (ajax) actions, exceptions and JavaScript errors.

First, the Components got two new utility methods, one to find out the source component of the (ajax) form submit and another to extract all actions and listeners from it as a list of EL expression strings such as #{bean.action}, #{bean.actionListener}, #{bean.ajaxListener}.

Second, the FullAjaxExceptionHandler got a new logException overloaded method with a LogReason enum argument which should help in determining when exactly the exception has been caught and whether it was successfully handled or not. For example, if handling has failed because the response was already committed, or the error page itself contained an error, then you could take additional action by sending an email to site admin.

About

Donate

For the ones who want to express their excessive thanks for my work, I used to have an Amazon wishlist with a list of books, but right now I don't have any interesting books on the list anymore (to anyone who've sent books before: thank you very much, I got 6 books in 6 months). You can always donate something so that I can use it for other stuff, such as Nespresso coffee.