Blogging Roller

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 

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.

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.

Found via Arjun: The My Yahoo RSS module appeared briefly yesterday on the Choose Content page under Personal Information Management with the name "Blogs", but it seems to have disappeared now. Here is a screenshot of the config page for the module:

The Roller backend is all interfaces. We have one implementation of the backend that uses Castor-JDO for persistence and we have another that uses Hibernate. It would be fun to try to create an implementation that uses the Blojsom file-store. The WeblogManager interface could probably be implemented using Blojsom, but what about the BookmarkManager and the NewfeedManager? Maybe those could be implemented by using OPML files.

Another excellent new Java blog on FreeRoller, this one by Merrick Schincariol. His entry on JAXB caught my attention. After waiting years for JAXB, I guess it is finally time to see how it stacks up against Castor-XML. Merrick likes it.

Winer's amazing new app that will cause people's brains to explode is just weblog search? I must admit, I'm a little disappointed.

In case you've missed it, Cameron Purdy has been benchmarking Java vs. .NET all week. Developers I talk to seem to take it for granted that .NET is faster than Java. Cameron's benchmarks tell a different story, though as Cameron admits "the author of the test can easily determine the outcome."

Patrick Peak continues his explorations of Struts, Webwork, and Spring. For me, comparing different technologies is the fast-track to understanding the technologies.

I know others have mentioned this before but, where are the Sun weblogs? Microsoft bloggers abound and now blogs are starting to show up on MSDN. Hey Sun, I'll help up Roller, no charge. Just fly me out to JavaONE and we'll discuss this further.

InternetWeek: IBM Preps DB2-Based Integration Software, New Dev Tools. Here are a couple of excerpts:

The new RAD tool is a model-driven development approach for developers unfamiliar with J2EE. One solution provider said the tool potentially could compete with WebSphere Studio, but Schurr said it is aimed at developers without Java expertise and is not specifically intended for skilled J2EE developers, which are the target customers for WebSphere Studio.

The new tools tend to confirm what every Microsoft-centric development shop that uses Rational fears: New and improved products will be Java-centric/exclusive and will first be available for WebSphere, then maybe available for Visual Studio .Net

That's why Microsoft and IBM battled it out for Rational. What is the upgrade path for those customers now? Does Microsoft do UML anymore? I can't seem to find any recent info on UML or MS Visual Modeler on their site.

I really enjoyed Sam Ruby's talk on SOAP at the Triangle JUG meeting tonight. Sam has a special skill for breaking things down to fundamental, easy-to-understand, thought-units, and then putting them back together and showing how the pieces fit together to do interesting things. Using this approach, Sam showed the audience that SOAP does not have to be complex and can be understood using the same view-source approach that we all used to learn HTML. He also took some shots at SOAP's dim-witted half-brother (those were not Sam's words) XML-RPC, but that flew right past the crowd because, frankly, outside of the meta-blogging clique, XML-RPC is just the fork that fizzled.