Blogging Roller

Anthony Eden: JBoss Group is causing a lot of problems with the whole Sun vs. JBoss stink and I think a lot of it is due to "management" decisions within the JBoss Group. Having another company offering support for open source development will hopefully bring the JBoss Group to terms with their corporate mortality and will cause them to rethink their attitude. Competition is always a good thing.

Lance Lavandowska: I believe Patrick is our first Switcher from another blog tool. I've seen a few people appear on FreeRoller, stating they came there from elsewhere, but this is the first instance of someone switching their own installation that I'm aware of.

When FreeRoller was attacked the other day, the system slowed to a crawl. I assumed that the problems were my fault and I started to look for performance problems. I noticed that we are running the RequestFilter, which is responsible for parsing the URL and handling request parameters, for every incoming request. The RequestFilter also hits the database to determine if the requested page and user are valid. Since many requests are for simple files, such as GIFs, JPGs, and CSS, this is not wise. So, I changed the Roller web.xml. I replaced this, which causes every request to go through the RequestFilter:

<filter-mapping>
    <filter-name>RequestFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

With this, which only puts page, rss, comments, *.do, and *.jsp through the ringer:

<filter-mapping>
    <filter-name>RequestFilter</filter-name>
    <url-pattern>/page/*</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>RequestFilter</filter-name>
    <url-pattern>/rss/*</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>RequestFilter</filter-name>
    <url-pattern>/comments/*</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>RequestFilter</filter-name>
    <url-pattern>*.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>RequestFilter</filter-name>
    <url-pattern>*.do</url-pattern>
</filter-mapping>

This seemed to have a significant effect on FreeRoller performance and on the MySQL load. I'm still looking at some Java code changes to optimize RequestFilter and RollerRequest, but the above change is easy to apply, so if you are running Roller 0.9.7 (or later), give it a try.

JavaLobby is still working on restoring the FreeRoller machine, which serves several purposes other than just FreeRoller, so FreeRoller will be down again, probably for the rest of the night.

Thanks to the hard work of Matthew Schmidt of the JavaLobby, the FreeRoller is back up and running. The server that hosts FreeRoller was attacked and Matt spent the day in the data center reinstalling/upgrading the OS, restoring FreeRoller, etc. Thanks Matt!

I just got word from JavaLobby that they are going to be taking the FreeRoller server down today for an OS reinstall. FreeRoller will probably be down for the rest of the day.

I had to do some addional work on the RollerWikiPlugin to get the plugin to work for RSS feeds as well as weblog pages. To do this I had to introduce a new concept: the EntryRenderer.

You might have noticed that FreeRoller has been pretty sluggish today and has been down a couple of times. The FreeRoller machine is experiencing some "technical difficulties" and the JavaLobby is working to resolve them as soon as possible.

This is a test of the RollerWikiPlugin, Roller's new JSPWiki powered Wiki plugin. I upgraded this site to Roller 0.9.8-dev this morning and the Wiki plugin is working great, check that link for a little user/setup guide.

Heading 2#

Heading 3#

Heading 4#

• item 1
• item 2
  • subitem 2.1
  • subitem 2.2
• item 3

bold and italics and external links

what about inline images?

Yes, everything seems to be working.

Here is the weblog entry text for this post:

This is a test of the RollerWikiPlugin. I upgraded this site 
to Roller 0.9.8-dev this morning and the Wiki plugin is 
working great, check that links for a little user/setup 
guide. If you read that, you'll understand why the comments 
link is missing from this post.

!!!Heading 2
!!Heading 3
!Heading 4

* item 1
* item 2
** subitem 2.1
** subitem 2.2
* item 3

__bold__ and ''italics'' and [external links|http://rollerweblogger.org]

what about inline images:

[http://www.rollerweblogger.org/resources/roller/leo5mo-sm.jpg]

Yes, everything seems to be working.

Oliver offers a very nice little HOWTO that explains how to enable comments on your Roller 0.9.7 or later weblog. However, he shows you how to do this using the old legacy $macros.

Moving forward, you should start using the new Roller Macros instead. Take a look at the User Guide section on Customizing your theme with Roller Macros for more information, or check the Wiki for a Roller 0.9.7 translation of Oliver's post.

Anthony Eden wrote:
> Oh, and in case I haven't made it obvious: this is an awesome release!

I think we're all glad that our labor's are finally available to 
"the masses." Thanks for the compliments. - Lance 

And thanks to you, Anthony, and to The JavaLobby, for providing FreeRoller. By the way, FreeRoller is now hosting 964 weblogs.

FreeRoller is down right now, so I'm assuming the upgrade is not just on the way, it is underway. YAY!

Patrick posts about Wiki-blog integration and wonders how Wiki-blog integration plays into the future direction of Roller. Here are my thoughts on that. Roller is first and foremost a weblogging system. I don't want to incorporate a Wiki into Roller, and I think the other Roller developers agree with this, but I do want to make it possible to integrate Roller with an external Wiki.

For now, Wiki-Roller integration means allowing weblog entries to be authored using Wiki syntax, making Wiki links in weblog entries link to an external Wiki, and allowing each weblog entry to have it's own Wiki link to an external Wiki, as Patrick describes.

I'm doing this integration by adding an (optional) Wiki plugin to Roller. I use JSPWiki for the Roller Wiki, so I'm creating the plugin using JSPWiki. I have this working now on my homebox (without code changes to JSPWiki), next, I'll create a Wiki-blog demo here on this site so you can see how it works.

Developing a wrapper class or API can be a way to add value to an existing API and can also be a way to isolate an existing API. Wrappers can be very useful, but when applied incorrecly, wrappers can be counter-productive and downright irritating. For example: the Coat-of-paint anti-pattern.

In this anti-pattern the developer wishes to isolate an API behind a wrapper, so he develops a very thin wrapper class for each of the classes in the API. Next, he procedes to use these wrapper classes throughout his code, but because the wrappers are so thin, his code still depends on the concepts, relationships, and often the method signatures of the wrapped API. The wrapper is like a coat-of-paint on the wrapped API, it changes the appearance of the wrapped API but does not truly isolate it.

A better approach would be for the developer to divide his code up into modules or "tiers," with each module having a well defined interface. Instead of isolating the API he wishes to hide behind a thin wrapper, the developer should have isolated the API by using it in only one of his modules.

UPDATE: Another, possibly more difficult, approach would be to develop an abstraction layer over the API that is to be isolated. If you will enventually need to switch out the wrapped API for some other API, then an abstraction layer is the way to go. It is a more difficult approach because, unless the underlying APIs are simple, developing a good abstraction over them can be a challenge.

It took a little more work, but I was able to come up with a JSPWiki-based Wiki plugin for Roller. I just committed it to CVS. It works just as well as the Radeox plugin that I did the other night. Now, I need to hook-up CamelCase links so that they point to a Wiki specified in the Roller config. Janne Jalkanen, the developer of JSPWiki, suggested that I develop a XMLRPCPageProvider, but I don't think I'll need to do that to meet my simple requirements.

I just committed new Radeox Wiki and Textile plugins for Roller. The Textile plugin works beautifully, but as I mentioned earlier, the Radeox plugin still needs some work. I used the open source Blojsom Textile plugin, but I had to follow Winer's rule and pay for the software by giving credit to Mark and Dave. Thanks guys. I would have used JTextile, but it relies on GNU regex and the code is not as pretty as the code from Blojsom.

I spent some time today hooking the Radeox Wiki engine into Roller so that weblog entries may be authored using Wiki syntax. This was amazingly easy to do, but I've got a ways to go before it is really useful. For example, I'd like to be able to tell the plugin where my Wiki is and then have it treat all CamelCase words in my posts as links into that Wiki. Since my Wiki is JSPWiki-based, I guess I'd have to do more than just telling the plugin where my Wiki is located. I'd also have to tell it how to form Wiki page URLs.

As a JSPWiki user, I prefer the JSPWiki syntax. JSPWiki syntax appears to be much more powerful than the Radeox Wiki syntax, but I'm pretty new to Radeox so I could be wrong about this.

Here is some Memorial day military history for you, courtesy of my great great grandfather and former Virginia State Senator John Newton Opie. This is an excerpt from Chapter XLIII of his book A Rebel Cavalryman.

After we returned from the Gettysburg campaign, the cavalry of both armies occupied our old ground in Culpepper County, until about the middle of September. We had a long rest here and no service except picket duty. Both sides, however, picketed in open country, with nothing between them. Our picket line ran along by Brandy Station, and immediately in our front, and in sight, was the Federal picket line. One day, being on picket, I waved a paper to a cavalry man on my front, and, hallooing to him to meet me half way, I rode out and he did likewise. We met and talked pleasantly for some time together, when, finally, I said, "Yank, got any Whisky?" Tapping his canteen, he said, "Yes, Johnny Reb." I pulled out some tobacco, and, in a minute, I had the whisky and he had the tobacco. This fellow amused me very much by saying that we did not fight fair. Upon my inquiring what he meant, he remarked, "The right way is to stand off and shoot, but you fellows run up on us." Well, I left my friend and rode back to my post, and pulled on my canteen frequently.

The chapter ends with Captain Opie spending three days in the brig, after riding into the Hampton Legion encampment and attempting to round the troops up for midnight review.

It took me a while to figure this out so... heads up! If you are using the MySQL Connector/J v3.0.7 JDBC driver then watch out for the infinite loop problem. This is a "known issue that happens when connections and statements are closed in particular circumstances." A fix will be included in the Connector/J v3.0.8 release.

In my case, this appeared as an intermittent problem with the Roller login. This problem appeared the other day on my site, causing Roller logins to fail, so I switched to one of the MySQL Connector/J v3.0.X nightlies and it seems to have solved the problem.

2003-05-25 03:08:27 HttpProcessor[10030][3] Starting background thread
2003-05-25 10:08:26 HttpProcessor[10030][2] process.invoke
java.lang.StackOverflowError
        at java.lang.Exception.<init>(Exception.java:41)
        at java.io.IOException.<init>(IOException.java:40)
        at java.net.SocketException.<init>(SocketException.java:29)
        at java.net.SocketOutputStream.socketWrite0(Native Method)
        at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
        at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:69)
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:127)
        at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:1478)
        at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:1405)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:879)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:945)
        at com.mysql.jdbc.MysqlIO.sqlQuery(MysqlIO.java:917)
        at com.mysql.jdbc.Connection.execSQL(Connection.java:1841)
        at com.mysql.jdbc.Connection.execSQL(Connection.java:1787)
        at com.mysql.jdbc.Connection.execSQL(Connection.java:1768)
        at com.mysql.jdbc.Connection.rollbackNoChecks(Connection.java:1369)
        at com.mysql.jdbc.Connection.rollback(Connection.java:1356)
        at com.mysql.jdbc.Connection.close(Connection.java:1028)
        at com.mysql.jdbc.Connection.cleanup(Connection.java:2050)
        at com.mysql.jdbc.Connection.execSQL(Connection.java:1853)
        at com.mysql.jdbc.Connection.execSQL(Connection.java:1787)
        at com.mysql.jdbc.Connection.execSQL(Connection.java:1768)
        at com.mysql.jdbc.Connection.rollbackNoChecks(Connection.java:1369)
        ...

A minor bug fix release. Download here.