Blogging Roller

I've only spent a little while working with MyEclipse, so perhaps I'm just a clueless newbie, but... I still haven't figured out how to get the JSP editor to work as expected or to avoid the 5-10 second startup every time I launch the editor on a new file. So far, I am not impressed.

Good news via <a href= "http://www.werner.be/blog/page/werner/20031025#myeclipse_3_6_3_eclipse">Werner and just in time too. I was getting ready to back out of Eclipse 3.0 M4 because my MyEclipse order was just approved and I assumed that MyEclipse would not work with M4. Now I don't have to back out.

I finally got around to reading Rod Johnson's Introduction to the Spring Framework on The Server Side and that inspired me to read the Rod Johnson interview.  I also read Patrick Peak's Dueling IoC post comparing the Inversion of Control support in the Spring and WebWork2 frameworks and some interesting comments on Matt Raible's Web Frameworks - which one should I learn post. Looks like there are some very useful things in Spring, but without actually using it, it's hard to tell whether Spring is a cohesive and elegant framework, or a hodge-podge of book examples and helper code for AOP, IoC , MVC, and JDBC. It did, after all, start out as example code for the book Expert One-on-One J2EE Design and Development. Spring deserves further study and because Springs features can be used a la carte (as demonstrated by the days old Struts Spring project), learning about Spring could pay off even for existing applications.

I also read Mark Pilgrim's excellent new XML.com column The Atom API.  The column reviews the history of weblogging APIs and then provides details of the new Atom API. The article makes it pretty clear that the Atom API is a better solution than the XML-RPC based Blogger and MetaWeblog APIs. It is easier to implement and it takes advantage of XML features like namespaces and schema. Atom is simple and elegant, yet it remains SOAP compatible; a great example of a web services API.

In other weblogging tech news, two competing proposals for website newfeed discovery have appeared: FDML from Sam "it's just data" Ruby and friends and shortly after that myPublicFeeds.opml from Dave "it's just an outline" Winer. These proposed standards could be pretty useful to sites like Java.blogs that aggregate multiple blogs and JRoller which host a community of blogs.

Simon Brown: I must admit that while XDoclet is very useful when building EJBs, I'm not sold on the idea of using for the web tier myself.

Like Matt and Erik, who both left comments on Simon's weblog, I'm sold on XDoclet for the web tier, for generating struts-config.xml, validation.xml, web.xml, form beans, etc.

People seem to understand the need for XDoclet code generation in the EJB world where there is a lot of boiler plate code and lots of ugly deployment descriptors to be written, but I've had a harder time convincing people to use XDoclet to generate web.xml, tag library descriptors, and Struts configs.

My coworkers understand the Servlet specification and they know the details of the web.xml DTD, so they see XDoclet as just another quirky tool to be learned. It seems to get in the way, it has bugs, and it is not always updated quickly enough for folks want to use the latest stuff (Servlets 2.4 for example). Learning to use the XDoclet tags is not all that difficult, the open source allows capable programmers to make bug and enhancements, but this is not very reassuring to folks who just want to add another Filter Mapping to web.xml, right now, damnit.

I've gone a couple of rounds with folks discussing pros and cons and I forgot the most obvious argument - continuous integration. The best reason to use a tool like XDoclet to generate web.xml, tag library descriptors, Struts configs, and other goodies is refactoring. If you have a bunch of Servlets, JSP Tags, and Struts Action classes in your code and you want to refactor your code by renaming classes and moving them between packages then you will have to carefully edit web.xml, your TLDs, and your struts-config.xml to correct all of the changed class and package names. If you were using the XDoclet @servlet, @jsp.tag, and @struts.action tags you would have no worries - all of your deployment files would be auto-magically updated.

Rumor has it that Eclipse 3.0 M4 will be released shortly and that a JSP editor will be included. Update: it is out now and the new feature list looks good. Another update: Werner Ramaekers provides a nice  summary of the new release.

At my day job, our product is finally approaching feature complete. Monday is the day we go to QA, so I'm working hard now to avoid working hard this weekend. The product and the new job in general has been a lot of fun. I've been able to learn a lot more about Struts, Struts Validator, Struts Tiles, XDoclet, JavaScript, JSP, and code generation.

The amount of code generation going on in our build process is just amazing. We start with a database schema definition DDL file that is marked up with funky XDoclet-style comments. From that we generate all of our business obects, JDBC code to persist these objects, auditing code, workflow code, Struts forms, and the english version of our I18N properties file. Our internally developed and Scheme-based code generator generates something like 90,000 lines of code based on a 900 line DDL file in about 3 seconds. Next, we run XDoclet over our code based to generate our Struts config file, Struts validator file, and our TLD. XDoclet is the dog of the build process; it takes about 10 seconds to generate a couple of hundred lines of code.

I don't know how we would have written this product in the time allowed if we had not used the code generation approach. Everybody is amazed at the progress and the agility we have in adapting to data model changes. The only problem raised by the code generation is customization. How can our consultants in the field customize our system when most of the code is "GENERATED CODE - DO NOT MODIFY"? The answer is that we won't consultants customize the code. Instead we'll try to make everything customer configurable through the product UI. That is our next challenge.

Werner Ramaeker speculates that Hibernate will become JDO 2.0 compliant.

As I was working on Roller, I kept the UI fairly simple. I didn't create any forms that needed to refresh themselves before making a final post. I tried to avoid using JavaScript except where absolutely necessary. I was pretty happy with Servlets, JSP, and Struts.

Now, I'm working on a Java-based web application with very complex forms. Some of the forms have multiple tree choosers, dynamic select boxes, popup windows with dual-lists, and popups that cause the page that launched them to reload. There is just no avoiding JavaScript and our requirements are pushing us towards complex solutions like inner-browsing to reduce the number of trips to the server for page reloads.

I can live with JavaScript and I'm taking the time to study up, but I'm becoming pretty disenchanted with web-MVC. I'm finding that, even with an web-MVC framework like Struts, maintaining the state of all of the form fields and UI widgets through page reloads and popup interactions is a real pain. There has to be a better way and, the more more I read about Java Server Faces the more I become convinced that it will be that better way. JSF will introduce UI components that can manage their own state, fire events, and, in general, behave more like true UI components. Sounds like the holy grail of Java web development. Do any of the existing Java web application frameworks support this kind of UI components today?

Welcome to Rick Ross and Matthew Schmidt of the JavaLobby who have recently started blogging with Roller.

First there was ASP, then JSP and PHP, then Struts, now there is JavaServer Faces, which has been years in the making and is Java's answer to .Net's Web Forms, offering the prospect of highly useable data grids and other controls. It also goes well beyond that role by providing a sophisticated control model for web applications that exceeds .Net's capabilities. JavaServer Faces can also be combined nicely with Struts.

I'm working my way through the JSF spec and wishing it was here now, so I'm really sorry I'm going to miss this one. Jay Cagle team lead of the Websphere Studio web tooling group will be presenting on JSF tomorrow night See the RTP-WUG site for details.

continues to dig in to the Roller source to identify, correct, and suggest workarounds for Roller bugs. Soon, we'll need a 0.9.8.1 release soon to incorporate his fixes. Good work Lowem!

That's right, Java/J2EE is a minivan. It is not sexy or hip like Ruby or Python. It is sensible, practical, gets the job done, and is relatively easy on the software industry environment. C#/Dot-Net, of course, is the SUV: crass, macho, and a real environmental hazard, especially to endangered species soon to be Redmond roadkill like Borland, Ximian, SourceGear, etc.

I can't believe that people feel the need to rag on Gavin King, the lead developer of Hibernate, because he joined the JBoss Group. They say he "sold out" and joined the dark side. What a crock. Do we really have to break up into JBoss, CDN, Open Symphony, and Jakarta camps and sling mud at each other? No, we don't! And really, who wouldn't quit their day job when they finally find a way to make their night job pay? There is no reason be upset, people. Unless, of course, they start charging for Hibernate docs. Then, my friends, heads will roll.

I walked out to my mailbox today to find that FreeRoller has vaulted everybody's favorite blowhard, the Howard Stern of Java blogs, bile-blogger Hani Suleiman to worldwide fame in the pages of Java Developers Journal. Hani's editorial, is just another in a series of unnecessary open-source-ain't-all-it's-cracked-up-to-be pieces from JDJ. The motivation for this most recent open source backlash? I guess JDJ feels the need to please it's advertisers and Hani feels the need to poke a little stick in the eyes of the JBoss group and Andy Oliver.

Hitting the racks this fall...

<a href= "http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471463620.html"> <img class="photo" border="0" align="right" src="http://www.rollerweblogger.org/resources/roller/book-josp.png" alt="Book cover: Java Open Source Programming" /> Java Open Source Java Programming by Joseph Walnes, Ara Abrahamian, Mike Cannon-Brookes, and Patrick A. Lightbody

I had the priviledge of reviewing a number of chapters from this book and found it to be not only a good introduction to WebWork, Sitemesh, and Hibernate, but also a great primer on test driven development and the use of mock objects in unit testing. It takes real disipline to do true test-first development and the authors of this book certainly have the disipline. The authors do whatever is necessary, sometimes writing scads of throw-away code along the way, to ensure that a test-first safety net is in place for each and every new development.

<img class="photo" border="0" align="right" src="http://www.rollerweblogger.org/resources/roller/book-projsp.png" alt="Book cover: Pro JSP" /> Pro JSP By Simon Brown, Sam Dalton, Daniel Jepp, Dave Johnson, Sing Li, and Matt Raible.

And now, from the shameless plug department... While you are book shopping you should also pick up a copy of Pro JSP, covering JSP 2.0, JSTL, database access options, Struts, XDoclet, and more. If you do, I'm sure I won't regret it.

O'Reilly's new <a href= "http://j2eegeek.blogspot.com/2003_09_01_j2eegeek_archive.html#106350631823650194">Tomcat book is a must have. He also has some nice screenshots from of the BEA JRocket Java VM management console and runtime analyzer. I would try JRockit, but I hate that whole -- it's a free download but you have to give us your email address and purchase is required for real use and we won't tell you the price unless you talk to a sales person on the phone -- deal.

<a href= "http://jakarta.apache.org/struts/userGuide/dev_tiles.html">Tiles seems to be a tough sell in my group, which includes a bona-fide JSP and web development guru. He has some good points. Tiles promises that you can define all of your page's layouts with a couple of template files. The goal is to reduce JSP code duplication and makes it easy to apply global changes to your site. But, if your pages use a completely CSS-driven layout and your site's entire look, feel, and layout can be changed by altering a single CSS file then what does Tiles buy you? To reduce JSP code duplication a couple of header and footer includes will do. Bringing a new web developer into a project is difficult enough with the Struts learning curve. Is the added complexity of Tiles really worth it?

About a year ago, Mike Cannon Brookes of Atlassian contacted me and offered to provide issue tracking for the Roller Weblogger project using JIRA, Atlassian's flagship web-based issue tracking software. I'd seen JIRA in action, so I took him up on the offer immediately. Mike set up a JIRA installation for us on an Atlassian-provided server, moved our old SourceForge bug-list into the system, and handed out usernames and passwords. We got the Atlassian legendary service, yet we didn't pay a penny.

Atlassian recently released JIRA 2.4 and to help get the word out, Mike Cannon Brookes has asked me to do a little review here on Blogging Roller. I like JIRA, so this is really no problem at all. I can give you my unbiased impressions of JIRA and the new JIRA 2.4 release without fear of retribution.

The old JIRA. First, lets talk about the old JIRA. When I started using JIRA, I was impressed by the clean, attractive, and easy to use user interface. Having worked with Scopus, PRTracker, and PVCS Tracker, nice UI was not what I had come to expect from a bug tracking system. Generally, things worked as I expected that they would and I found it was easy to tweak the settings that I needed to tweak. I added the names of the Roller components (e.g. Weblog Editor, Page Management, Installation, etc.) for issue categorization. I also added the release numbers of the previous and planned Roller releases. I've been using JIRA for a year now and it has been working well for me, it doesn't get in the way, and doesn't irritate. That is high praise for software.

The new JIRA 2.4. Roller's JIRA installation is still running the old JIRA 2.3, so to review JIRA 2.4 I had to install it myself. I downloaded the new JIRA 2.4 from the Atlassian site and installed the standalone version. The standalone version comes bundled with a copy of Tomcat 4.1 and the HSQL-DB database, so there is almost no setup. All you do is unzip, run the startup script, and point your browser at http://localhost:8080. Very cool and perfect for a quick review like this. You may also install JIRA as a standard Java Web Application Archive (WAR) or Enterprise Application Archive (EAR) and Atlassian provides step-by-step instructions for all of the major Java app servers (plus Resin and Orion). After starting up Tomcat and filling out a couple of JIRA setup screens, I had JIRA 2.4 up and running.

I created a test project and a couple of issues and found no major changes in the JIRA user-interface along the way. That makes sense. JIRA 2.4 is a minor enhancement and bug fix release. The most significant new features are a new bar-chart display for issue statistics, support for customization via the Jelly XML scripting language, and some improvements in custom field support. There are a host of other improvements and fixes. JIRA 2.4 is not a ground-breaking new release; it is a more stable, new, and improved version of the JIRA.

JIRA Limitations. There are a couple of major JIRA limitations that should be mentioned. I've seen JIRA lose a couple of deals (to TeamTrack and DevTrack) because of these limitations, so I'm hoping that Atlassian will address one or both of them in the next major release. First and foremost: out-of-the-box JIRA does not support full integration with any of the major Source Code Management (SCM) systems. The extensive JIRA API and plugin service and listener appear to provide all of the hooks customers need to implement full intregration, but missing out-of-the-box SCM integration can be a deal killer. The other limitation is the workflow. The workflow that is built into JIRA cannot be altered though the UI or through the three JIRA extension mechanisms (the API, listeners, and services). You can change the names of the issue states, but you cannot change the states and transitions in the issue workflow. This can also be a deal killer as many customers are either unwilling or unable to change their processes just to please a new software package.

Overall, JIRA is a simple, easy-to-use, and very flexible web-based issue tracking system with that provides a high-level of extensibility though Java APIs, plugins, and soon a SOAP-based web services interface. Installing JIRA is very straight-forward, the default settings are reasonable, and this allows you to get up and running quickly. JIRA sports some innovative features like voting and RSS feeds for issue events, but JIRA does not try to do as much as more complex, expensive issue tracking systems like TeamTrack. JIRA has a couple of major limitations, but the JIRA pricing helps to make up for those limitations. You can get a JIRA server license that allows unlimited users for the price of a couple of TeamTrack client licenses. If you want a low-cost and highly extensible web-based issue tracker for your software project then you should take a close look at JIRA.