Blogging Roller

One of the appealing things about Webwork is that Webwork actions are not tied to the web (i.e. the Servlet API) in the way that Struts actions are. You can use Webwork as a generic action framework, implement your business APIs as actions, and then re-use those APIs behind any UI technology: web, Swing, AWT, command-line, etc. You've probably heard WebWork advocates tout this genericity as a major advantage of Webwork over Struts. According to Anders Hovmoeller, writing to the WebWork mailing list, it is the key advantage of WebWork over Struts:

Anders Hovmoeller In my opinion, the only really solid argument for using WW over say Struts is that we are not locked up in a certain environment. I firmly believe that the core parts of XW can easily avoid being tied up to servlets, as WW does now.

But this is opinion is not shared by all WebWorkers. Rickard Oberg, the original architect of Webwork (who recently resigned from his position as architect of the project), does not see it that way. This is from a Jan 13, 2003 post on the Webwork mailing list:

Rickard Oberg That WebWork turned out to be a generic command pattern was more of an accident then by design. Because of this genericity WebWork is not optimally designed for doing web work. Some of the "plumbing" needs to be done by actions themselves, instead of having it be done by the framework. I want to make WebWork/XWork *better* suited for the web, because that is what *I* *need*. I want to get more for less. I don't give a damn about making it work well in Swing. If it does, then whaddyaknow, cool. If it doesn't, shit happens. If there's ever a point where I need to decide between "keeping genericity, or making it work better for the web", the latter is a given.

If you are considering using Webwork instead of Struts for your webapp, you might want to follow along on the Webwork mailing list to see where it is heading. Is it continuing along the generic "XWork" framework path or will it turn and become even more web-friendly?

The LinkbackExtractor that I posted yesterday uses the Swing HTML parser, which is built into Java, but there are other Java-based HTML parsers available. Erik Hatcher suggested the JTidy HTML parser and there is also the HTMLParser project on SourceForge. Know of any others?

Looks like a very interesting talk this month at the RTP Websphere Users Group meeting. Shakeel Mahate will talk about Struts in general, and Thomas Roche will talk about the Struts tooling that IBM has cooked-up for Websphere Application Dev Studio (i.e. the high-end version of Eclipse). I'll be there, deadlines be damned!

This was one of the comments on my Eclipse 2.1 M4 out of memory! story:

Ted Stockwell: Yep. And the more third-party plugins you use the worse the problem will get. You can thank SWT for that. Java developers aren't used to dealing with the mindless drudgery of explicity releasing any and all resources that they use. It's back to the bad ole days of C++ resource management for SWT developers.

I don't know enough about this to refute it, but I never noticed any memory problems with Eclipse before M4 and I am using the same plugins now as I did before.

The other comment on the story was from a person named 'gizmo' who recommends that I start Eclipse like so: eclipse.exe -vmargs -Xmx256m.

Elliotte Rusty Harold: JavaWorld has announced that they're going to start charging $49.99 for access to back issues, which they define as anything more than a week old.

Good thing I didn't publish the Roller article on JavaWorld.

I moved over to Eclipse 2.1 M4 recently and, for the most part, it has been working great. However, I have to restart it every hour or two because it keeps on running out of memory.

I've been trying to figure out why Mozblog will not work with Roller's Blogger API implementation. I haven't had much luck, but I have again come across an irritating little issue with the Servlet API request.getRequestURL() method. I'm calling on the blog support line for advice.

Tomcat/Servlet experts, what do you make of this comment from Roller's RollerContext.getContextUrl() method?

 // If you are running Roller behind a foreground server, 
 // then your Servlet engine may be operating on a different
 // port than your forground server. For example, I run Roller 
 // on a Tomcat background server that operates behind an 
 // Apache foreground server. My Apache server is on port 80, 
 // but my Tomcat server is on port 1003.
 //
 // If this is the case, then request.getRequestURL() may 
 // return a URL that is valid but that includes an unsightly
 // and unnecessary port number that you would rather not 
 // include in weblog permalink. In other cases (e.g. you are 
 // running a standalone Tomcat instance on port 8080) the port 
 // number is essential.
 //
 // To deal with this the Roller getContextUrl() method uses 
 // a configuration parameter to determine if it should include 
 // a port number. It calls request.getRequestURL(), parses apart 
 // the result, and builds a context URL suitable for use in a 
 // permalink with or without a port number.

Is that clear? Is there an easier way to deal with this issue?

Boy, Jeremy Zawodny sure is easy to irritate. I think the word physical refers to the physical layer of a network. If your database is remote, then a new database connection may require a new network connection. Don't forgo connection pooling just because you are using MySQL, you will still gain significant benefit from using a connection pool.

An IBM-backed Java tools initiative could be yanked back into Sun Microsystems Inc's sphere of influence, to heal a potential community rift, through efforts lead by Oracle Corp, <a href= "http://www.theregister.co.uk/content/53/28615.html">writes Gavin Clarke [The Register].

Despite the ridiculous sounding introduction, the article in fairly interesting. As I have mentioned <a href= "http://www.rollerweblogger.org/page/roller/20021113#i_really_missed_the_point">before, Oracle is pushing for a standard IDE plugin-API so that Eclipse does not become the universal standard tools platform. However, this doesn't line up with that effort:

"[Members] want to drag Eclipse back in-line with Sun... SWT versus Swing has put some tension in the organization." [Ted Farrel, Oracle]

He can't be suggesting that IBM rewrite Eclipse using Swing, that would be crazy, so he must be suggesting that SWT becomes part of Java.

According to Patrick Chanezon, BEA Workshop is ready for butter and jam and there only three IDE players left:

IBM builds momentum around Eclipse. New members sign on to program, but not Sun or BEA [InfoWorld: Web Services]

There are 3 players left in the java IDE game: Sun, IBM and BEA.

With IBM having bought Rational, I think BEA Workshop is toast. Too bad it looked real nice. How long before they port it to the Eclipse platform :-)

What about IDEA IntelliJ?

What about Borland, who now owns both JBuilder and the Together Control Center?

I don't think you can write them off just yet.

Speaking of that "real nice" BEA Workshop GUI: last night at the TriJUG meeting, Chris Garrett of TogetherSoft demonstrated the Together Control Center BEA Workshop Accelerator.  The Accerator allows you to build web services for the Weblogic server in a graphical manner using a UML-like notation. These web services use the Weblogic Workshop's server-side framework, but the Weblogic Workshop GUI is not involved in the process in any way.

TogetherSoft may have no need for the BEA Workshop GUI, but BEA has not given up on the Workshop at all.  According to this InfoWorld article, BEA is "expanding [the Workshop] into a full-blown development environment for not only Web services but also for pages, for server-side components, for visual controls, visual interfaces, the whole nine yards"

This might be interesting:

Next on my plate: I'm digging *back* into Struts, so I can compare how Struts and WebWork compare directly. [epesh]

It should be a good one too. Chris Garrett of TogetherSoft Borland will be discussing how WebLogic Workshop (formerly known by the codename Cajun) and Together Control Center may be used together to consume 100% of your CPU cycles create web services. I'm just joking, of course. I love playing with those cool GUI dev-tools. Too bad I can never afford to use them past the end of the evaluation period. Thank goodness for my whiteboard, Ant, and Axis.

I'm pretty sure that I first heard the term "brute force debugging" from my mom, who is also a programmer. I was writing about debugging this weekend, so I tried to find the origin of the term via Google. I didn't find the origin, but I did find some interesting <a href= "http://www.cs.colorado.edu/%7Ehendrixs/classes/lectures/lecture_10.pdf">lecture notes on debugging by Susan Hendrix of the <a href= "http://www.cs.colorado.edu/">Univ. of Colorado, Boulder. I really like Hendrix's guidelines for debugging. The first two are think and sleep on it. Great advice, wouldn't you agree? I really need to do more of both, whether I am involved in debugging or not.

Hendrix really doesn't like brute force debugging. She says that there are three brute force debugging techniques: 1) use of dumps, 2) scattering print statements randomly, and 3) over-reliance on debuggers. That doesn't sound quite right. My mom taught me that brute force debugging was the practice of placing well positioned print statements in code to locate where a bug is occuring. I like that definition better, but it is my mom's definition so what do you expect? If my mom was still programming today, I bet she'd be using Log4J, or something similar, instead of brute force debugging, no matter how you define it.

Thomas Mahler posted comment on my recent <a href= "http://www.rollerweblogger.org/page/roller/20021212#carlos_on_hibernate_vs_ojb">Carlos on Hibernate vs. OJB story and I'm promoting it to a post. I do not want to be unfair to OJB and I'm glad to hear that the issue of stolen code was a simple little mistake. Here is what Thomas had to say:

As one of the core OJB developers I'd like to correct some points.

- OJB is not focussing on JDO. OJB is focussing on transactional object persistence. We provide several "personalities" to give users their API of choice.
We currently support ODMG3.0, JDO1.0 and our own abstracted Object level transaction API (called OTM).

OJB has a layered architecture with a persistence kernel reponsible for all the O/R stuff. This kernel is shared by all three toplevel personalities.

We have *not* been working on JDO for months. We are concentrating on a stable 1.0 release. JDO is in the 2.0 scope! So statements like "OJB is losing its way by focussing on JDO" do not make any sense.

- OJB did not steal any code! We have a little JDO prototype that has not been maintained for months. By accident one of our developers checked in some interface definitions from the JDORI codebase. These interfaces were not even referenced by our actual code! We settled this issue within hours by simply deleting the stuff from our CVS.

I don't see why such a minor incident should prevent us from building a OSS JDO implementation?

While on this topic, I should also thank Carlos for explaining why he does not like JDO and for pointing out that there is another open source JDO implementation called TJDO. I should have remembered that because I mentioned TJDO in my <a href= "http://www.rollerweblogger.org/page/roller/20021013">comparison of persistence frameworks back in October.

Carlos says that, right now, the Hibernate persistence framework is a better choice than Jakarta OJB. He also criticizes Jakarta OJB for it's emphasis on JDO.  I have to agree with his assessment of Hibernate vs. Jakarta OJB, but I don't agree 100% with Carlos on JDO.

Carlos does not like JDO, but like it or not JDO is the standard Java persistence API.  Currently, there are only a few small vendors supporting JDO (SolarMetric, SignSoft, and PrismTech to name a couple), but someday JDO could become the defacto standard.  If that happens, then support for the JDO API will a very important feature.  For that very reason, I wanted to use Jakarta OJB in my WROX JSP chapter on database access.  However, I found that the Jakarta OJB implementation of JDO was just not ready for prime-time. I wanted to use an open source framework, so I decided to use Hibernate instead. Plus, the Hibernate docs are very nice.

Now, it has come out that (apparently) the Jakarta OJB implementation of JDO contains some stolen code.  I guess that means than an open source version of JDO is not going to happen, at least not in the near future.

I can't speak about the technical merits of JDO.  I don't know enough about JDO to compare JDO vs. any other persistence API.  Perhaps somebody who does (Carlos?) can break it down for us.

<a href= "http://www.raibledesigns.com/page/rd/20021211#design_patterns_marc_fleury_and">Matt <a href= "http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg11563.html">posted the #java chat-channel FAQ's recent critisms of Struts to the Struts mailing list, provoking Ted Husted to come to the defense of Struts. Ted took apart the criticisms one-by-one and left the attacker with nothing but a lame argument "not really quantifiable through bullet points" that "Struts just feels wrong."

Even without those bullets the #java FAQ author continued to fight on with a rebuttal that explains "#java tends to sneer at morons who feel that Struts is THE WAY." Ah, now I understand. The FAQ question should rephrased. It should not be "why are people so down on Struts?" The real FAQ is "why are the snotty geeks in this chat room so annoyed by Struts?" The answer is simple: sour grapes.

I'm sure that there are plenty of valid criticisms of Struts, and that nobody wants to hear those criticisms more than the Struts contributors themselves. Tell them.

Erik pointed to the Log4J write-up titled Don't Use System.out.println the other day and yesterday it was the hot story on Javablogs (I kid you not). This does not really have anything to do with Log4J, but here is what the Webpshere best practices paper that I mentioned earlier says about using System.out.println in a web application:

Minimize use of System.out.println.  Because it seems harmless, this commonly used application development legacy is overlooked for the performance problem it really is. Because System.out.println statements and similar constructs synchronize processing for the duration of disk I/O, they can significantly slow throughput.

I did not know that.

Say what you want about big bloated Websphere, but the developer resources, redbooks, white papers, etc. on the Websphere and DeveloperWorks sites are great.  After I wrote most of my WROX JSP chapter on performance, I found a very helpful white paper on Websphere Development Best Practices for Performance and Scalability (340kb PDF).  As far as I can tell, the best practices apply to any J2EE application server, not just Websphere.  Many of the recommendations apply to EJB applications only, but there are also a good number that apply to plain-old Servlet/JSP apps, for example:

• Don't store too much in each session
• Don't create sessions at all if you can avoid it
• Use database connection pooling
• Avoid string concatenation
• Minimize thread synchronization
• Don't use SingleThreadedModel

I had already covered most of the areas mentioned in the white paper, except the thread synchronization and string concatenation tips. I'll add those too. I'm not sure why they don't mention page caching.

The other day, I posted a new version of my Ag persistence example on SourceForge for download. This new version includes the HSQLDB database and is a lot easier to install and run than before.

I have to agree with David Jordan's most recent OnJava article. "Castor JDO" is a confusing name for a product that does not support JDO. I don't know or care who was using the JDO acronym first; the Castor folks need to drop JDO from the Castor name.