Using Nexus and the Nexus REST API for implementing a software update tool
Nexus is using a pretty well documented REST API which is usable externally as well.
For one of my customers I implemented a kind of automatic software update tool that can be embedded into any product. It is based on the Sonatype NEXUS repository manager.
Java5 Generics are implemented by type erasure, but …
… still it is possible to get hold of the actual type parameters of parameterized types. Even if classical reflection does not deliver type information, this type parameters can still be extremely useful. I have a few pieces of code (DAO, controllers, etc.) that are parameterized by class objects.
A simple ViewController for JSF
Very early Apache Shale came up with the idea of providing a view controller that allowed to execute dedicated methods (annotated, etc.) during various JSF life-cycle (phase) events for doing initialization work upfront for example. As Shale was hibernated, Apache Orchestra stepped in and added many more useful features.
Both frameworks are based on the idea of having a dedicated page bean (a JSF managed bean per view) that would control important processing steps for the entire view (page).
It requires following naming conventions in order to associate a page bean to a view, optionally a view controller mapper provided the ability of explicitely associating page beans and views.
Resource versioning in JSF2
JSF2 made an promising attempt to provide versatile resource versioning but obviously has failed this. After I had used weblets for a while I tried to migrate some JSF2 web application to adhere to this standard. Unfortunately I had to figure out that resource versioning does not work as it has been proposed in the JSF2 spec.
Rendering a FacesMessage reliably
Quite a while ago I had posted about generating a FacesMessage within a method that is called during the RENDER_RESPONSE phase. Today I had to find a way to display those at the very top of a page and none of the message should get lost.
So I came up with trying that with jQuery (in my case it is already included in Rich-Faces that I was using here). The idea is to actually render all FacesMessage objects at the very bottom of the page and once the page has finished loading move its DOM tree up where it was supposed to be displayed.
Enable Dovecot SSL
/etc/dovecot/dovecot.conf requires these settings
ssl_disable = no ssl_cert_file = /etc/ssl/certs/certificate.pem ssl_key_file = /etc/ssl/private/key.pem
The certificate and key must be created before either using the dovecot tools or the way I’m describing that in-depth.
SASL + Postfix with Debian Lenny
In the last days I have reinstalled a mail server on a new virtual host and upgraded from debian etch to Lenny. The initial set was done by a friend of mine following this instructions. With the upgrade to Lenny however a few adjustments were required. So I describe the new setup here.
The dreading timezone issue with JSF and how it hits you again with daylights saving
JSF is converting all date/datetime types into GMT base for rendering. This can cause a date offset of n-hours to be shown depending on the timezone you are in. You have 2 choices to deal with it:
Either you implement an application wide (global) date converter as described here or you add the timezone attribute to each of the convertDateTime tags.
Extending the FacesContext (and using a Faces Factory)
JavaServer Faces has always been sold as a piece of flexible and extensible code. It really is. Through its factory facilities you can bend and twist that web framework until it fits. Today I tried to resolve something that has bothered me a long time. For a showcase I have implemented a few supporting lines of code that come handy in lots of places. When prototyping something, that code often ends up in some abstract base class from which managed bean are subclassed or it even ends up in some “helper” class with static methods. In the end you don’t feel that it is at the right place.
Close a PrimeFaces dialog when no validation messages are available
I’m posting this to memorize a PrimeFaces pattern for reuse. The visibility of PrimeFaces dialog panel can be controlled using the visible attribute. JavaScript widget.open() or widget.hide() modify the visibility state as well.
<p:dialog widgetVar="widget" id="dialog"
visible="#{not empty facesContext.maximumSeverity}">
<f:facet name="header">
<h:outputText value="Form" />
</f:facet>
<h:form>
<h:panelGrid columns="3">
<h:outputLabel for="input" value="Input" />
<h:inputText id="input" label="Input" required="true" value="VALUE" />
<h:message for="input" />
</h:panelGrid>
<h:panelGroup>
<!-- update the form for the case we get validation errors -->
<p:commandButton value="Update" update="dialog"/>
</h:panelGroup>
</h:form>
</p:dialog>
