Bill Gates & I

... agree on at least one issue:  Donald Sadoway's lectures (3.091) are way too cool to miss!

OpenID woes

Today's topic is the Acegi plugin (Spring Security) for grails . It doesn't work out of the box. This guy seems to have done some work with it and even claims to have the thing working for his site, but even if my user authenticates at myopenid.com I'm still not allowed into my experimental site. *grrr* (this was more of a rant than I wished when I started writing, but that is how things work out sometimes).

Update: I figured out what was wrong ;) It was simply that when typing in my OpenID URL, (http://xxxx.myopenid.com) I was inconsistent with regards to typing a terminating "/" or not. Big difference! acegi uses the entire url as an user identifier, and a difference of one character makes a difference. I would characterize this as a bug, since it means that semantically identical but syntactically different URLs map to different user identities.

It's the small things that makes life worth living

Today I added OpenID login to a project I am working on.  I used the OpenID plugin for grails, but it didn't work properly.   Only after a long while did I figure out the reason:

• The application is called "widgary", and grails by default gives it the url http://.../widgary
• I don't like this, so I forced Jetty to set the context path to "/".
• The plugin doesn't grok this, it wrongly assumes that it is -only- the .../widgary/.. path that is valid, and hence no openid logins work.

During the course of this (*ehrm*) discovery process, I also discovered that the spring security plugin (formerly called acegi  plugin) is probably a better choice, so perhaps I'll end up using that now that I know how to make plugins work ;)

Couple of interesting things

Ubuiquity is of course mandatory these days.  It's nice to see that kind of crativity being inherited (second generation Raskin ;).

Also I found brightkite  (here too)which seems to be exactly the kind of location aware application we have been dreaming of the last decade finally making it into something resembling mainstream.

Making web servers accepting chunked uploads

I've finally grown sick and tired of the fact that most web servers seems to be quite unable to accept chunked upload. This is a serious problem since Java ME insists on using chunked upload and I'm working on Java ME software ;)

So we know that Apache/PHP seems to work. Tomcat possibly works in some situation. Jetty doesn't work.

I wish to use Groovy on Grails to develop nice services for mobile phones, but since Groovy by default uses Jetty I need to fix Jetty. My test case ws to use a WebAlbum application I found on the net, and modify it to use the Object tags introduced in widger to allow image content uploads from forms.


I check out the svn repository , but Maven won't build :-/ By asking the very nice people at #jetty @irc.codehaus.org I discovered that this was due to a bug in maven 2.0.9, and that 2.0.8 or 2.1 would probably work. Being an adventurous soul I chose Maven 2.1.0-M1, and sure enough now Maven worked. Unvortunately it was not a clean build, since an unit test failed. The kind people at #jetty had a look at the test and indicated that the failure was probably nothing to worry about, so I disabled it (by renaming LifeCycleListenerTest.java to LifeCycleListenerTest.java-not) and sure enough everything else seemed to build and test quite nicely.

I then installed the newly built binaries into grails's lib directory and verified that chunked upload does indeed not work with a freshly built jetty. I then set out to work. Instrumenting the GrailsParameterMap.java file in Grails, indicated that the MultipartHttpServletRequest parser in Spring for some reason return nothing, instead of something when parsing the input. Instrumenting Jetty's HTTP parser indicated that it continued to read HTTP input after Grails had already thrown an null pointer exception for trying t0 work with nonexistant input. I then spent the better part of a day to install an instrumented version of spring (spring is -h-u-g-e-!) and making it work with my already installed grails. Well, after too many hours I got a combination of consistent spring and flow to compile, install and combine with grails. I then set a trap inside spring, to capture the setting of the result of a multipart parse, and discovered that the culprit probably (but so far not for sure) is in Apache's file upload package. When faced with a multipart and chunked input from the web server (Jetty in this case) it returns an empty map of parameters. It turns out that the fix is simple: Replace the commons-fileupload-1.1.1.jar file with commons-fileupload-1.2.1.jar, and things just work. Whee. Now I can get back to my real task, which is to make intersting web based applications for the brand new widger web client ;)

Opening ceremony

This is a blog from the Open Nordic conference in Skien Norway 19-20 june 2008.



It is very very painful to listen to public officials who cannot speak English trying to do so from a podium. Nuff said.

Implementing ODF in Belgium (Bart Hanssens)

This is a blog from the Open Nordic conference in Skien Norway 19-20 june 2008.



Belgium. 10.6 million people, dense population, three languages (Dutch, French, German). Very little layering of public services. All the various parts of the government has a high degree of autonomy.

odf-converter.sourceforge.net: A converter using .Net 2.0 and 3 separate .MSIs. Can convert stuff here and there. Integration with MS-office OK, pretty good .doc conversion, but not quite there yet. A bunch of rough edges but mostly useful.

He mentioned a lot of other stuff as well. It seems to be sort of useful, but still a whole bunch of rough edges. If you want to ODF is probably useful for prime time today.

His presentation was not the most inspiring one, so I spent spent most of my available attention on reading mail and news ;-)