Category: java

Designing JSF pages with the usage of the <f:ajax> tag can be a pretty frustrating affair.  For example, if you’re trying to build a table with Ajax behavior, it often won’t work the way you expect it to. For example imaging a table with a delete-button which changes the content of your table:

<h:panelGroup layout="block" 
   id="artikel_table_id" 
   binding="#{artikelTableContainer}">
	<table>
	<ui:repeat var="bookingItem" value="#{childItemController.childItems}">
		<tr>
			<td>....</td>
			<td><h:commandLink value="delete"
				actionListener="#{childItemController.remove(bookingItem.item['numpos'])}">
				<f:ajax render="artikel_table_id"/>
			    </h:commandLink>
			</td>
		</tr>
	</ui:repeat>
	</table>
....

This example won’t work even if it looks logical. The problem here is the render attribute pointing to the id of an outer h:panelGroup. This UI component tree is created during the initial build of the view.  If You’re manipulating the component references after building the view, the changes will not be reflected in the UI component tree during a ajax event life-cycle if you do not care to also execute the compete tree.

To solve this you can change the render attribute in the following way:

<f:ajax render="#{artikelTableContainer.clientId}" 
        execute="#{artikelTableContainer.clientId}"/>

In this way now you have a binding to a component instance which forces jsf to execute and to rebuild the complete UI component tree. Note:  the execution is necessary to update input fields placed within a table row.

ui:repeat versus c:forEach

At a first look it seems that between ui:repeat and c:forEach there is not big difference. This is true if only want to visualize a data set. But if you want to manipulate the entries too – e.g in a table with an embedded edit-mode than you can run in trouble if you are working with an ui:repeat. As explained in the example before, the elements inside a ui:repeat are not part of the component tree. This becomes an issue if your entries are editable. It will work on the first look if you simply submit the outer component. But in case of a JSF validation error, which is initiating the JSF-Life-Cycle the component tree will lost your entered values.

For that reason it is recommended to use a c:forEach tag instead of a ui:repeat if your data set is editable.

Enclosing Ajax Tags

If you use an enclosing ajax tag like in the following example, please note that you need to use a c:foreach instead of ui:repeat :

<h:panelGroup binding="#{artikelTableContainer}"> 
  <f:ajax onevent="updateOrderItems">
  <table>
    <c:forEach var="orderitem" items="#{childItemController.childItems}">        
     <tr> 
       <td>....</td>
       <td><h:commandLink value="delete"
        actionListener="#{childItemController.remove(bookingItem.item['numpos'])}">
      <f:ajax render="#{artikelTableContainer.clientId}" 
          execute="#{artikelTableContainer.clientId}"/>
      </h:commandLink> 
   </td> 
  </tr> 
 </c:forEach> 
</table>
</f:ajax>
</h:panelGroup>

In this case you should not call the ‘execute’ in the enclosing ajax!

Using Apache Cassandra as an highly available  Big Data Platform is in my eyes a good choice as Cassandra Cluster is easy to handle. We are using Apache Cassandra as an archive platform for our human centric worklfow engine Imixs-Workflow. But how does Cassandra perform with large files?

If you start with Cassandra you have to change the way how you use databases, especially when you come from the SQL direction.  Although Cassandra can handle very large amounts of data easily, you have to consider the concept of the partition size. This means in short that the data within a partition (defined by the Partitionkey) should not exceed 100 MB. If you plan to store large files (e.g media files) you need to split up your data into smaller chunks. In the following I will explain in short how this can be done. Continue reading “Cassandra – How to Handle Large Media Files”

Today I implemented a javax.ws.rs.client.ClientRequestFilter for a form based authentication. The FormAuthenticator class can be used in combination with a javax.ws.rs.client.Client  to interact, for example, with a rest api secured by a login form. Such a login form in Java EE typically uses the request URI ‘/j_security_check‘ with the form input fields ‘j_username’ and ‘j_password‘. As a result of a successful login the browser stores a cookie named “JSESSIONID” which need to be send with every request.

The request filter can be added to a javax.ws.rs.Client like this:

....
// create a javax.ws.rs.client
client = ClientBuilder.newClient();
// create new formAuthenticator
FormAuthenticator formAuthFilter = new FormAuthenticator(rest_api_url, 
     userid, password);
// register the filter...
client.register(formAuthFilter);
// now you can GET, POST, ....
....

You cam find the source code of this filter class on GitHub.

If you have any ideas for improvements your comments are welcome!