Archive for July, 2006


The heat in Vienna is unbearable. Even overnight, it doesn’t get below 30 degrees celsius (in my flat, that is.) So instead of Java and JSF it’s just two pictures I took recently.

As part of the “Donaukanal” revival (the Donaukanal being a regulated branch of the Danube that passes through the inner city) a swimming swimming pool opened last week. Take an old barge, apply blue paint, and there’s your exclusive in-town cooling facility. Prices are moderate, though, and it’s five minutes from our office…

When not cooking its sole inhabitant, there are some nice sunsets to watch from my place. Here’s today’s sunset…

On an unrelated note, I spent a nice evening with my ex-partner yesterday. From a curious geek’s perspective it’s interesting how slow history seems to fade. Then again, nostalgia would probably be a more fitting term. To quote Murray from DeLillo‘s fabulous novel White Noise:

I don’t trust anybody’s nostalgia but my own. Nostalgia is a product of dissatisfaction and rage. It’s a settling of grievances between the past and the present.

(note to self: read this.)

Leave a Comment

Beware of Remote Interfaces

In the process of porting a not-yet-open-source EJB3 project to run in Sun’s Glassfish container, a working colleague of mine had to convert all local interfaces to remote ones, since Glassfish does not publish local interfaces via JNDI (unlike JBoss), making them unavailable to our own JNDI-based interface lookups (that were introduced because JBoss’ Tomcat on the other hand did not support injection via @EJB in web applications and we had some trouble with start-up dependencies in MBeans).

Besides making everything slower and exposing some not-so-serializable objects, it was amazing how much serialization was going on in JBoss (latest CVS 4.0.4) even though everything ran in the same VM. Mistakenly we were under the impression that in this case JBoss would automagically detect local calls to remote interfaces and enable call-by-reference (in the EJB sense) if a local interface was available. We were going back to local interfaces anyway – but now it’s a top priority.

On the other hand, two lessons learned:

  1. Automated unit and integration tests are essential, they revealed most problems almost instantly, and
  2. It is a bad idea to use fat static objects as parameters, especially when they are not serializable. It works fine and seems to be elegant and efficient with local interfaces, but totally screws you if remote interfaces are involved. In this case, the problem was a static collection of configuration parameters that contained XStream instances to serialize objects to XML. While this may or may not be a great idea (since XStream objects are pretty big and are thread-safe anyway), it worked in the local case – and failed with remote interfaces, since XStream objects themselves are not serializable. Storing them in an internal static array in the constructor does not work either, since the parameterized constructor is not called on deserialization. Now it’s just a single XStream object, initialized in a static constructor – it’s a bit less elegant since all class aliases have to be defined in a central class, but it’s definitely more resource- (and remoting-) friendly. So instead of
    public ObjectParameter(XStream xStream, ...) {
        this.xStream = xStream;

    we now use a single static XStream instance, initialized in the class’ static constructor:

    private static XStream xStream;	
    static {
        xStream = new XStream();
        xStream.alias("queryOperatorNode", QueryOperatorNode.class);

Leave a Comment

Passing parameters to links in Facelets

I’m a JSF/Facelets newbie – so far there’s been a lot of cursing, but also some moments when I had the impression of “something done right”.

In JSF, command links are used to wire buttons to actions in backing beans. Unfortunately, you cannot pass parameters directly to the action method – but you can set parameters in your backing bean before calling the action. To set a parameter, add a f:param to the command link body – e.g.

<f:param name="myParameter" value="#{myValue}"/>

In the backing bean, the passed value can be retrieved from the faces context (similar to HttpServletRequest#getParameter for servlets). It works, but it’s inconvenient and errorprone, and requires conversion for all but string parameters.

Fortunately, there are alternatives. There’s the non-standard Tomahawk updateActionListener that directly works on bean properties. For example, you could just write

   property="#{myBean.myProperty}" value="#{someValue}"/>

and forget about it. Unfortunately, Facelets doesn’t include the updateActionListener out of the box. But in JSF 1.2 there’s something even better – the setPropertyActionLister. It works exactly like the Tomahawk listener, but it’s standard and hey – it’s already been backported to Facelets 1.1:

   target="#{myBean.myProperty}" value="#{someValue}"/>

So far it’s worked great and it is definitely better than manually setting parameters via f:param.

Comments (14)

Ant error reporting

Having spent hours (literally) on a minor ant build file improvement – enabling an instrumentation task conditionally through a system property – I just wonder if I had taken this long, had ant more strict syntax checking. I admit that

<target name="emma" if="${emma.enabled}">

should not be expected to work if the correct form is

<target name="emma" if="emma.enabled">

But instead of just assuming the conditional to be false in the first case, a warning message would have been nice. Of course I should have read the docs – “the name of the property that must be set in order for this target to execute” – but I’m reluctant to do that when I’m convinced it always worked this way before.

Leave a Comment

Ruby better than JSP?

Bruce Tate (of Beyond Java fame) wrote a combined JSP-rant/Ruby-for-the-web article in which he claims that

  1. JSP is crap (agreed),
  2. Embedded Ruby templates are better than JSP (no objection either),
  3. and thus that Ruby is better suited for web development than Java (huh?).

Ignoring the fact that JSP is outdated and many better alternatives exist (Facelets, Tapestry, Freemarker, …) and that there’s even Groovy Templates, I don’t see the ruby templates/components described as something desirable. They’re great for hacking small webapplications, but each line of code embedded in a template/component inevitably creates maintenance problems. Sure, we do need looping and conditionals for templates, as well as output formatting routines – but that’s it, and you don’t need Ruby or Java for such a task. Code inside a template is hard to debug, hard to test, and hard to refactor.

Seaside, a Smalltalk-based web application framework, looks pretty interesting from a programmer’s point of view, but I doubt any non-programmer will adopt to that way of thinking:

renderContentOn: html
	html heading: 'Hello world' level: 1.
	html paragraph: 'Welcome to my Seaside web site.  In the future you
		will find all sorts of applications here such as: calendars, todo lists,
		shopping carts etc'

It looks great – for a programmer, and as long as your designer colleague can get his job done using pure CSS. I’m not too sure Smalltalk will take off for web development as did Ruby, but it would be interesting to see more work done in this direction for other languages (in contrast to HTML templating).

Overall, Bruce Tate’s conclusion that “other languages such as Ruby handle Web development much better than Java technology” is not supported by his article. However, this doesn’t make Ruby on Rails any less impressive than it already is – for anyone doing web development, regardless of his/her language of choise.

Comments off {

First Post!

After years of writer’s block I intend to start writing about “things” (probably programming-related) again, not just hacking code and comments and sending the occasional email. That is, after I figured out what wordpress can do for me, since the options are pretty overwhelming for a blogging-newbie like me.

Cheers, Daniel

Leave a Comment