Monday, November 1, 2004

Further Adventures with Roller Weblogger

Fun with UTF-8

Take a quick peek at Figure F.


Well, not complete success, but hey . . . it didn't crash! (click for larger image)

You can see that while the screen did come up, it really doesn't look too good at this point. Scrolling down through the page, I could see that the entire page was just filled with UTF-8 (Universal Transformation Format-8) line-feeds and carriage returns. As Roseanne Rosannadanna's Nanna used to say, "It's always something!"

My first thought was the realization that the WebSphere Application Server doesn't come up out of the box with UTF-8 support enabled. I rarely have occasion to use UTF-8, so I had to look up the hoops that you have to jump through to turn that on.

I'd step through all of that here if it weren't for the fact that it had absolutely nothing to do with the problem. So we'll just forge ahead and pretend that I never really wasted all of that time and energy.

My next thought was that I didn't really know the status of MySQL's default UTF-8 support, so I did the research on that. It turned out to be another pointless waste of time, since that wasn't the heart of the problem either.

The heart of the problem, which I eventually stumbled upon through no fault of my own, was that I had simply loaded the database with that data. By this time, no amount of translation or support by any product would have made any difference.

I had just cut and pasted the insert statements from the demo database load file, which was designed for HSQLDB, and executed it under MySQL. MySQL interpreted all of the &#92u000a and &#92u000d text as simply text, and put that text into the database tables.

To correct this problem, I just brought the load script up in a text editor and performed the following "find and replace" actions:

&#92&#92&#92u000du000a to &#92n
&#92u000a to &#92n
&#92u000d to &#92n
admin to jchilton

That last item I threw in there because I realized that since I was using an external LDAP (Lightweight Directory Access Protocol) directory for authentication, and not the Roller user database, there wasn't going to be any way to work with either of the pre-defined Weblogs because there was neither an admin, nor a testuser1, on the existing LDAP directory.

Once I completed the changes, I rebuilt the database from the new load script and went back to Studio to try it once again.

3, 2, 1 . . . again

Once more, I right-clicked on the Web project to bring up the context menu and selected Run on Server. When the main Roller page came up, I clicked on the link to the Weblog formerly known as admin (now renamed to jchilton) and found myself looking at Figure G.


Now, that looks much better. (click for larger image)

Not too bad!

I clicked around a little bit and everything seemed to be working as it should. Then I went out to the other Weblog that comes bundled with the demo and did the same.