Arjan Tijms' Weblog

In Java EE, JPA (Java Persistence API) is used to store and retrieve graphs of objects. This works by specifying relations between objects via annotations (or optionally XML). Hand over the root of an object graph to the entity manager and it will persist it. Ask the entity manager for an object with a given Id and you'll get the graph back. This is all fine and well, but how in this model do we control which branches of the graph are retrieved and to which depth branches should be followed? The primary mechanism to control this with is the eager/lazy mechanism. Mark a relation as eager and JPA will fetch it upfront, mark it as lazy and it will dynamically fetch it when the relation is traversed. In practice, both approaches have their cons and pros. Mark everything eager and you'll risk pulling in the entire DB for every little bit of data that you need. Mark everything lazy, and you'll not only have to keep the persistence context around (which by itself can be trou...

In JPA one can define JPQL queries as well as native queries. Each of those can return either an Entity or one or more scalar values. Queries can be created on demand at run-time from a String, or at start-up time from an annotation (or corresponding XML variant see Where to put named queries in JPA? ). Of all those combinations, curiously Hibernate has never supported named native queries returning a scalar result, including insert, update and delete queries which all don't return a result set, but merely the number of rows affected. It's a curious case, since Hibernate does support scalar returns in non-native named queries (thus a scalar return and named queries is not the problem), and it does support scalar returns in dynamically created native queries (thus scalar returns in native queries are not the problem either). An example of this specific combination: <named-native-query name="SomeName"> <query> INSERT INTO foo...

In JSF input components have a label attribute that is typically used in (error) messages to let the user know about which component a message is. E.g. Name: a value is required here. If the label attribute isn't used, JSF will show a generated Id instead that is nearly always completely incomprehensible to users. So, this label is something you definitely want to use. Of course, if the label is going to be used in the error message to identify said component, it should also be rendered on screen somewhere so the user knows which component has that label. For this JSF has the separate <h:outputLabel> component, which is typically but not necessarily placed right before the input component it labels. The problem The thing is though that this label component should nearly always have the exact same value as the label attribute of the component it labels, e.g. <h:outputLabel for="username" value="Username" /> <h:inputText id="user...

The problem JSF allows you to bind an input component to a model bean via a so-called value binding. A notorious major headache is that a null is automatically coerced into a zero (0) when the bounded property is of type Integer or Long. This behavior only seems to rarely be the required one. A number of other types are coerced as well, e.g. in case of Boolean it's coerced to Boolean.FALSE . Finding a solution Although coercing is a literal interpretation of the spec, it seems that basically only Tomcat that implements this somewhat peculiar behavior. They have a setting to turn this off: -Dorg.apache.el.parser.COERCE_TO_ZERO=false See e.g. jsf: integer property binded to a inputtext in UI is set to zero on submit If you're in a position to use this option, don't read further and use it. If you can't use this option (you have e.g. a big system, lots of testing needed) and a null is needed at only a few places, another option is required. One possibi...

Arguably one of the most convenient things in EJB after declarative transactions is the @Asynchronous annotation . Applying this annotation to a method will cause it to be executed asynchronously when called (the caller does not have to wait for the method to finish executing). The downside of this annotation is that it's only applicable to EJB beans. While EJB beans these days are lightweight and nothing to avoid in general, the fact is that in Java EE 6 and especially Java EE 7 other managed beans, specifically CDI ones, play an increasingly important role. These beans unfortunately can not directly take advantage of the platform provided @Asynchronous . Building such support ourselves in Java EE 7 however is not that difficult. Thanks to the Java 8, and the Interceptors and Concurrency specs it's actually quite simple, but with a small caveat (see below) : We'll start with defining the annotation itself: @InterceptorBinding @Target({METHOD}) @Retention(RUNTIM...

PrimeFaces provides a convenient and easy to use sorting facility for its DataTable . Together with Facelets, this facility allows us to create re-usable columns that are natural sortable by default. E.g.: <ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:p="http://primefaces.org/ui" > <p:column headerText="#{headerText}" sortBy="#{value}"> <h:outputText id="#{id}" value="#{value}" /> </p:column> </ui:composition> Such a column can be used on a page inside a DataTable as follows: <my:sortableColumn id="foo" value="#{someBean.someValue}" /> The problem The above is only a simple example, and real-life usage can be more complex with e.g. default styles and cell editing capabilities added. With such complex tags, i...

The problem JSF, via Facelets, has various mechanisms to easily reuse view content. One of those is the Facelets tag, which allows one to reuse markup and/or components . One notorious problem with these Facelets tags is that you can't directly pass action methods (method expressions) into them. There's a workaround where you break the expression into two parts, the base (which should be a value expression) and the name of the method as a plain string. Inside the tag these two are then combined again, e.g. via the array notation syntax. See e.g. Passing action methods in Facelets using array notation Facelets Param for action method Another approach is to create a small helper tag that converts the value expression in some way into a method expression. There have been a couple of implementations of this idea: Creating composite controls with JSF and facelets How the button is created and how it acts (see ActionMapperTagHandler at the bottom...