Raible Designs

[Review] Java Open Source Programming

Today I finished reading Java Open Source Programming. It took me one week to read - and I only read about an hour a day. This book is nice to read - you can breeze through 20 pages in no time. I appreciate a quick-read technical book. I enjoyed the simplicity of this book, especially since I'm such a rookie at WebWork, SiteMesh and Mock Objects. I knew most of the Hibernate and XDoclet stuff, but I did manage to pick up a few tricks, and since it's the only book on Hibernate (that I know of), I'll refer to it when I need to do components or proxies. Overall, this book made WebWork and SiteMesh look like great technologies and I'm excited to start using them.

The sample app, PetSoar, continues the "call your persistence layer from your action class" that I've seen in all WebWork sample apps. I still don't know if this is a good idea, but since Actions aren't tied to the web, maybe it is. This means you put your business logic in your controllers (a.k.a. actions). Kinda breaks the whole controllers should only be controllers mantra, but whatever floats your boat. To be honest, in AppFuse, all the Managers (a.k.a. business layer) do is transfer POJOs to ActionForms, and then back again. The Managers are were my business logic should go, but I often find it easier to put it in my actions. I sense a paradigm shift - will the WebWork version of AppFuse only contain a "dao" layer and a "web" layer? Who knows - only time will tell.

One interesting thing I picked up is the different way that Dependency Injection (a.k.a. Inversion of Control) is handled in WebWork compared to how its handled in Spring. In Spring, all you need to do is add a setter (and local variable) to prepare a class for IoC. When using WebWork, you have to create an Interface that has the setter defined, and then your Action must implement that interface. If Spring can do it without an interface, why can't WebWork?

All in all, I enjoyed this book - though it didn't peak my interest as much as J2EE Design and Development. I think that's probably because Spring solves some issues I've had with AppFuse (binding interfaces and implementations), whereas this book doesn't really solve anything for me. As a WebWork newbie though, I do feel this is a good read. I also found myself saying "Wow, that's cool" a fair amount of times (re: SiteMesh and WebWork).

I was disappointed that i18n was not covered at all. I tend to always prepare my Struts apps for i18n (extracting text into a .properties file). However, in most cases, a 2nd translation has never been put in place. So, I bitch about the lack of i18n coverage, and I write my apps with i18n in mind, but it's never been used in any of the apps I've written. Maybe I should just quit doing i18n in my apps - it'd probably save an hour a week of development time.

So it comes down to this - if you don't know anything about WebWork, this book is a worthwhile read. If you know WebWork - I'm sure you'll be disappointed because it is written for newbies.

Next up, upgrading my programmer certification to 1.4 with the Sun Certified Programmer & Developer for Java 2 Study Guide.

Anyone else having trouble with SourceForge's CVS?

SourceForge's CVS repositories have been acting up since yesterday - at least for me. I just did a clean checkout of AppFuse and I got version 1.0. WTF? Even ViewCVS shows that my latest code is there. Wierd.

A few thoughts on AppFuse

I've been thinking about how to structure AppFuse for the upcoming Spring and iBatis enhancements. These enhancements shouldn't require any directory structure changes. However, I've received some suggestions to change the common, ejb and web directory structure to be a little more inline with the tiers. So it would become something more like database, business and web (or dao, service and web). After thinking about this for the last couple of days, it seems to make sense. I picked up the notion of common from Erik Hatcher's JavaDevWithAnt, which I borrowed heavily from when creating AppFuse. Erik used common because this represented classes that would be included in both the web tier and the EJB tier. But since I (currently) don't plan on every adding EJBs to AppFuse, does it make sense? Even if I did, I'd probably only use SessionBeans, and those could easily fit into the service layer. The nice thing about moving the business layer (currently in web/**/services) to it's own directory is that it will get it's own JAR (with hardly any modifications to build.xml) and can be used outside of the webapp.

The nice thing about isolating the web directory to web-only classes is I can use Ant to replace any Struts-specific classes with WebWork or Tapestry. To prevent AppFuse from being cluttered with too many options, it'll ship with Struts out-of-the-box. If users want WebWork for their framework, they can download a WebWork version of the web-tier and run an Ant target that will replace all the Struts stuff with WebWorks stuff. It seems like the cleanest way to do web framework switching.

Another thing that might happen to AppFuse, caused by my enthusiasm to try out everything, is that it will contain too much stuff for a basic web application. It currently has security and user management built in, which is what most webapps need. I recently added in OSCache and Clickstream. OSCache is not enabled, but most webapps can probably use it somewhere. Clickstream is a different story. For most of the webapps I've built, this is not needed at all. Most of the apps are no more than 20 screens, and it's unlikely the client will care where people go the most. Another option that deserves ripping out is the idea of Struts' submodules. I tend to rip this out as the first thing when starting a new project. File Upload is something I've used rarely, so I should probably lose that feature too.

There are also other technologies that I've thought of adding to AppFuse, namely Quartz and Lucene. However, I've only used Quartz on 1 of my last 5 projects and Lucene on 2 - so obviously these might be considered bloat for a basic webapp. I think the best thing would be to implement these in AppFuse, on my own, and then document how I did it on the wiki (for an example, see diagramming build.xml with Vizant). If folks need to use it they can add it on their own. Documentation is always good, and if I can just document how to add stuff, I can certainly reduce the bloat.

Whaddya think - is it better to include options out-of-the-box or simply document them? Should I restructure the directories to match the tiers more?

If you're planning on using Spring...

If you're planning on using Spring with Hibernate, Data Access with the Spring Framework is a must read. This article makes it look easy (and simpler) to use Spring's Hibernate helper classes than the regular Hibernate API. Good stuff - this kind of stuff makes integrating Spring into AppFuse look like fun. Deleting code is always fun. I wonder if MyEclipse will roll in some support for the Spring Framework? What about IDEA? Yeah, I broke down and bought a copy. I could use some "get to know your IDE" tutorials though. One thing I learned from Open Source Programming (and originally from The Pragmatic Programmer) is get to know your IDE. I could certainly use some more expertise on Eclipse and IDEA. I'm going to buy MyEclipse, a good Eclipse book and go read some IDEA documentation. Ambitious plans right before bed - sure sounds good though. Links appreciated - I want to make my IDE-life easier.

Tomcat 5.0.18 Released

Download or read the Release Notes. You know what bugs me about this release? The release notes suck! There's no changelog - what bugs got fixed, which ones didn't? Any new features? I suppose I could go crawling around their bug tracker and find out, but isn't this the kind of information you'd like to see with the release? Should I upgrade? Why should I upgrade - is something broke in 5.0.16 that's fixed in 5.0.18? Are there memory leaks that got fixed?

The only reason I develop on 4.1.29 these days is because my Remember Me feature works on 4.1.x, but not on 5.0.x. I could make it work on 5.0.x, but it wouldn't be as secure. I hope to implement Charles' recommended cookie strategy and then go for 5.0.x as my development platform, but that'll be a few more days.

On another note, I've implemented the Tomcat Ant tasks in AppFuse and I must say, these things are nice. The main advantage is speed, which all developers love.

Turn off sessions in your JSPs

One of the tips I picked up in J2EE Design and Development was to turn off automatic session-creation in your JSPs. So I tried this today on my project, and it doesn't seem to work. Basically this involved putting the following at the top of your JSPs:

<%@ page session="false"%>

I did this by adding this to my taglibs.jsp, which is included in every other JSP - so it should affect all my JSPs and prevent a session from being created on my welcome-file - right? Not according to Tomcat's Manager application - it still increments the number of sessions as I hit the welcome page with different browsers. Am I doing something wrong?

I'd love to get this working - so sessions are only created when a user logs in. Those JSPs that need a session, I'll override the default with session="true". I often see a whole bunch of sessions on the wiki and roller apps on this site - and in reality - a session should never be created, unless I login. At least I think that's how this is designed to work...

Can your laptop do this?

Another reason why PowerBooks rule: I starting running "ant test-all" right before I left for the office this morning. I closed the lid as it was starting Tomcat to run Cactus tests. When I got to the office, I opened the lid, and Tomcat continued starting and all the tests finished running. Can your laptop do that?

Poor Open Source Developers

Richard seems to think that most open source developers are like starving artists:

While a few make really good money selling consulting and training and other services, the vast majority of open source developers don't make anything.

For some reason, I don't believe this. The open source projects I participate in, as well as the ones I admire and use - all seem to have developers that are gainfully employed and making money. Of course, this may just be a Java open source phenomenon.

To do open source, you have to have a day job. You can't expect open source to feed your family or even your cat for that matter. As I said there are exceptions, but most open source developers do it for the love of writing software. While commercial software developers do a great job of feeding their families, open source developers do a better job of feeding their minds. In the end, you have to ask yourself which is more important: The things you own or freedoms you have.

Very good points. I dig working on AppFuse, as well as Roller, Struts Menu, and the Display Tag because I can do whatever I want. I can implement silly features like Clickstream and I don't have to ask anyone if it's a good idea (I'm still debating this).

Back to my point though. I firmly believe that most Java Open Source Developers are gainfully employed and not starving artists. Part of this comes from the fact that most of the big projects I work with (i.e. Struts and Hibernate) have some smart folks on staff, and the popularity of their projects has provided them with more opportunity, hence they're employed.

Personally, I do open source because I want to learn. I want to write code that gets scrutinized by the masses. As an independent consultant, I rarely get another person looking at my code - so I turn to the community by opening my code (that I use on a daily basis) to other developers. Overall, having others look at my code has resulted in much higher quality software for my clients, and has helped me learn a lot in the process as well.

I also look at open source development as a good marketing campaign - here's what I can do, hire me. This has proved very successful so far. Hence, my formula: Open Source Development = good marketing = gainful employment.

Mock Shmocks!

Let me start this post by saying that I've never used Mock Objects in my JUnit tests. Simon digs it, crazybob is an advocate and so is the gang that wrote Open Source Programming. In fact, the OSP book says that your unit tests should only take a couple of seconds to run! A couple of seconds!? Mine aren't that fast, which definitely makes me think I should look at Mocks to try to speed things up.

However, there is a method to my madness. Almost all my tests depend on a database connection and use DBUnit to populate the database before running. This can be time consuming, but it's not too bad for what I'm getting: real tests that verify the environment, not just the code. I just ran all tests in the application - 8 minutes 7 seconds - for 165 JUnit/Cactus tests and ~25 WebTest (JSP) tests.

If I did use Mocks, I wouldn't have discovered all the bugs in my code this week. When migrating from MySQL to DB2, I found that some things worked on MySQL, but they didn't on DB2. I modified the code, doing some tweaks to make Hibernate happy, and voila - now everything works on DB2 and MySQL. Furthermore, all my errors occurred when running my app in the container, and when I used simple JUnit tests (on my Managers) to test the same logic, it worked.

Who knows, I'm definitely learning new stuff everyday. Maybe it's possible that Mocks could do all this, but testing the production environment seems pretty important to me.

Coldtags - I dig the product and the support

I noticed from reading JavaLobby's Weekly News that Coldtags has a new version:

Coldbeans Software announced the major new release of Coldtags suite. This suite provides 160+ custom JSP tags for common programming tasks faced by JSP developers. And now this suite includes custom tags similar to web controls in .NET framework.

Find out more here: http://www.servletsuite.com/jsp.htm

I currently use the Country tag and the State tag and they're awesome (simple, but still something I needed). One feature I'd like to see is XHTML compliance for these tags, so I send them an e-mail.

Any chance of making this (and statetag) XHTML compliant? It would basically involve allow assigning an "id" attribute ("style" would be great too) and changing SELECTED to selected="selected".

Lo and behold, I got a quick reply less than an hour later:

Hello Matt,

it will be done.

Best regards,
Coldbeans support

P.S. I would like to note that the wish list for any component is open. So, feel free to suggest new features/options etc. you or your clients need and we will add them to upcoming release. Your suggestions for new components are more than welcome also.

Sweet! Note the P.S. - send your suggestions if you have any.

One Hour Later: Both tags have been updated with new attributes, and it's now XHTML-compliant. ;-D