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>
Getting started with eclipse RCP development
Lars Vogel is maintaining a really helpful set of up-to-date articles about eclipse RCP programming.
Blackberry unlocking
A few days ago I had to unlock 2 of my Blackberry devices, a Curve 8300 and a Bold 9000. Yesterday a friend asked me what service I had used. It was unlockberry.co.uk and I was really satisified with the service they provide. However, I recommend that you use their (Black)berry logger software that reads device internal parameters and send that to their team after you have purchased unlocking. That seems to be more reliable than selecting the device type and the network provider.
Spring has its own Expression Language as of version 3.0
Recently I have switched from the log4j logging framework to the logback framework. logback seems to have evolved into something better than log4j. It has cool features like the ability of logging into context specific logging files almost out-of-the-box (Using a sifting appender).
However the application has to provide the context (usually as MDC variables) which is kind of boring task to do.
So, I have implemented a fairly generic servlet that is able to provide almost any servlet request information for an active HTTP request. This servlet accepts a set of SpEL expressions (SpEL will be available with Spring 3.0) which are parsed and evaluated.
Finally it produces the evaluation results as MDC variables through the org.slf4j.MDC api (So I guess that might be usable for log4j as well).
slf4jmdc at...SpringExpressionSlf4jMdcRequestFilter mdcKeyExpression contextPath=${request.contextPath};username=${request.userPrincipal?.name}
@Override
protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
StandardEvaluationContext context = new StandardEvaluationContext(new RootObject(request));
ExpressionParser parser = new SpelExpressionParser();
String[] mdc = StringUtils.delimitedListToStringArray(mdcKeyExpression, ";");
Properties expressions = StringUtils.splitArrayElementsIntoProperties(mdc, "=");
Enumeration keyNames = expressions.propertyNames();
while (keyNames.hasMoreElements()) {
String key = keyNames.nextElement().toString();
try {
Expression exp = parser.parseExpression(expressions.getProperty(key), new TemplateParserContext());
Object value = exp.getValue(context);
if (value != null) {
MDC.put(key, value.toString());
}
} catch (ParseException e) {
LOGGER.error("Parsing expression", e);
}
}
try {
filterChain.doFilter(request, response);
} finally {
while (keyNames.hasMoreElements()) {
MDC.remove(keyNames.nextElement().toString());
}
}
}
This servlet can be used about anywhere MDC variables are needed!
