Book | JIRA | Confluence | Forum

20040802 Monday August 02, 2004

Spring Live Reviews and Status Category: Writing

Spring Live is getting some positive reviews - which is always nice to see. Chapter 6 is almost done in tech edit and should move on to copy edit in the next couple of days. I plan to start Chapter 7 (Persistent Strategies) this week. I hope to spend two mornings at the local bagel shop and write enough to where I need to show some code. Then I'll spend a few late nights coding MyUsers to use Spring JDBC, iBATIS, JDO 2.0 and OJB. After that, I should be able to finish the chapter by putting in a late night and full day. That worked for Chapter 6 - I hope it works for Chapter 7.

Chapter 8 is on unit testing and Chapter 9 is on AOP. Chapter 9 is going to be tough to finish by the end of August, but I really hope I can pull it off. Julie is due on Labor Day - and if I don't finish it before our 2nd baby comes out - I'm afraid it might be another month. I think we'll plan on publishing 1.0 with 8 chapters, and if I get on a role, then it'll have 9. From there, I plan to start with the following list of update chapters:

  • Chapter 10: Transactions
  • Chapter 11: AppFuse
  • Chapter 12: Security (will include Acegi)
  • Chapter 13: MVC Integration (covering WebWork, Tapestry and JSF)

I know there's some interest in a chapter on JMS, so I'll probably do that as #14. Chapter 14 will be the first chapter of 2005 if I can get Chapter 9 done for version 1.0. If you'd like to see the update chapters changed in any way, please post a comment. I'm open to removing, re-arranging or adding any you'd like to see. Remember - there's 12 of them!

In addition to getting Chapter 6 finished and writing the code for Chapter 7, I hope to get JIRA and Confluence installed this week. Then I can start entering bugs from the first 5 chapters - and fixing them too. Thanks to all for the feedback so far - keep it coming! (2004-08-02 01:35:55.0) Permalink Comments [4]

20040730 Friday July 30, 2004

SourceBeat Authors have it made Category: Author

I didn't realize SourceBeat authors had it so good. Apparently, we're the only ones that get flown to conferences and put up in hotels. This past week, I heard that some other publishers balk at this and wonder how the business model can sustain this. So I asked Matt and James (the head honchos) and their answer was simple: we don't have to worry about distribution channels. Traditional publishers have to shell out up to 50% of their revenues to places like Amazon and book stores.

Not only is SourceBeat a kick-ass publisher for paying our way to shows - they're also a blast to hang out with. And it's not just the publishers, it's the authors too. Whether its listening to James talk about growing up in Alabama, Jonathan reminisce about voting for Nixon or Bruce giving motivational speeches - it's definitely a good time. I feel like I'm part of something - rather just working with someone who's going to publish my book. I can't wait until the next conference! SourceBeat - making authoring fun again. (2004-07-30 18:13:25.0) Permalink Comments [3]

20040728 Wednesday July 28, 2004

[ANN] Spring 1.1 RC1 Released Category: Spring Live

Download or read the Release Notes.

Awesome work gents! All tests pass in AppFuse (OS X, Tomcat 5.0.27, Ant 1.6.1, MySQL 4.0.16). If you're using Velocity or FreeMarker with Spring - you should definitely checkout the new macro libraries for working with forms. The OJB support is pretty damn cool too - I can't wait to dig into it for Chapter 7.

[OT] I'd like to thanks Spring Developer Colin Sampaleanu for his recent help on AppFuse. He's been dissecting it and showing me ways to improve its usage of Spring. He even upgraded its Spring+iBATIS support to version 2.0. Thanks Colin! (2004-07-28 13:40:04.0) Permalink Comments [4]

20040727 Tuesday July 27, 2004

Recommendations for Struts+Spring Category: Spring Live

Juergen posted some advice for using Spring with Struts on the springframework-user mailing list today. If you're using Struts+Spring, this is probably worth reading.

In general, I recommend the following:

  1. Define all your common middle tier beans in a root context (typically "/WEB-INF/applicationContext.xml"), loaded by ContextLoaderListener/Servlet. This includes your JDBC DataSource, Hibernate SessionFactory, DAOs, business facades, etc. Those do not have to be aware of Struts at all, but are rather available for any component in the web application: They could be shared by Struts Actions and plain Servlets, for example.
  2. You can then access all those common middle tier beans via WebApplicationContextUtils, from any web resource that has access to the ServletContext, be it a Servlet, a JSP, a Filter, or a Struts Action. This is also what the OpenSessionInViewFilter for Hibernate does. As your middle tier beans are not defined in a Struts context but rather in a generic one, they are available in that generic fashion.
  3. ust use the ContextLoaderPlugin for Struts to define Struts Actions as beans (typically in "/WEB-INF/action-servlet.xml", provided that your Struts ActionServlet is named "action"), i.e. in combination with DelegatingActionProxy or DelegatingRequestProcessor. Its context will only contain Struts Action definitions then, receiving bean references to middle tier beans. You will never need to access such a ContextLoaderPlugin context directly.
  4. The Spring-provided base classes ActionSupport and DispatchActionSupport allow easy access to the root context loaded by ContextLoaderListener/Servlet. If you use those Action base classes rather than defining Struts Actions as Spring beans, do not use ContextLoaderPlugIn at all. Simple access your middle tier beans via getWebApplicationContext().getBean(name) calls. This is the simplest way to access Spring-managed beans from Struts, actually.
  5. If you still decide to define common beans in the ContextLoaderPlugIn context for Struts, do not fetch the ServletContext attribute directly but rather extend your Struts Actions from the ActionSupport and DispatchActionSupport base classes again, which also allow easy access to a ContextLoaderPlugin context. I do not recommend this, though: Put your common middle tier beans in a ContextLoaderListener/Servlet context.

Good stuff - thanks Juergen. If you're looking for a simple Struts+Spring+Hibernate sample app, you can download MyUsers - the sample app in Spring Live. This app simply uses the ContextLoaderPlugIn to load applicationContext.xml and action-servlet.xml. After reading Juergen's advice, I should probably re-factor it to use a Listener + the ContextLoaderPlugin.

The main reason I'm using the ContextLoader Plugin to load everything is because it's much easier to write my Struts Action tests with StrutsTestCase. StrutsTestCase currently does not invoke listeners when using MockStrutsTestCase. I suppose I could use mocks to separate my actions from the middle tier. This might be a good candidate for some integration -> unit test refactoring in Chapter 8. (2004-07-27 05:36:37.0) Permalink Comments [9]

20040725 Sunday July 25, 2004

Managing the source for Spring Live Category: Spring Live

One of the difficult things I'm finding with Spring Live is maintaining the source code for the sample chapters. The reason is because it's not a one time "develop and release" thing. I want to maintain and update the code in the chapters as new versions of dependent projects are released. Maybe I'm doing too much, but it seems like a good idea.

My current strategy is to use CVS and create branches for each chapter. Right now, there's a branch for Chapter 2 (Struts+Spring), Chapter 4 (Spring MVC), Chapter 5 (Advanced MVC) and I'm about to create one for Chapter 6 (view options). The major reasons for the branching is so I can modify the source for each chapter as if it's a separate release. The pain of doing this is that if I need to update a library in the app (i.e. SiteMesh 2.1), I have to do it in 4 different projects. Ugh. Anyone know of a better way to control the source?

The other day I was thinking that Maven's multi-project support would be perfect for this. I could have one "core" project for the database access stuff and several other projects for the different chapters. The problem with that is I don't want to impose Maven upon readers. I also believe the multiple module setup makes it more of a "book application" than a "how I would do a project" application. Suggestions are most welcome. (2004-07-25 19:56:09.0) Permalink Comments [3]

20040724 Saturday July 24, 2004

Diffing the changed chapters between releases Category: Spring Live

After receiving feedback on ERP-1, I can see an issue that's going to come up with SourceBeat's "keeping up with the source" model. For instance, I upgraded the Spring Live sample app to use SiteMesh 2.1 and had to upgrade some chapters accordingly. Also, in Chapter 5, there's a warning about a bug - and now it's fixed in Spring 1.1.

I can tell there's going to be a need to show readers what's changed between releases. By releases, I mean ERPs and monthly chapter updates. Even though you've read a chapter, some things in that chapter might change when the next release comes out. It's simply the nature of open source software. If I truly want to write an up-to-date book, I should keep every chapter up-to-date.

So here's my idea: treate the book like an open source project. Readers can enter bugs and the author notes which bugs are released when a new version of the book comes out. If we use this system, the author would make sure a bug (or enhancement request) is entered before they change a released chapter. That way, we can link to fixed bugs for each release - giving the reader a nice and quick summary of what's changed. For example, here's the release notes from SiteMesh 2.1.

How does this sound? Any other ideas for managing "what's new" between releases? (2004-07-24 15:49:31.0) Permalink Comments [1]

20040721 Wednesday July 21, 2004

FreeMarker vs. Velocity Category: Spring Live

The last couple of days, I've managed to convert the MyUsers sample app from JSP to Velocity, and also to FreeMarker. Since this app uses SiteMesh, this was fairly easy thanks to its Velocity Decorator and FreeMarker Decorator support. Of course, Spring supports both technologies as well - ref: Spring+Velocity and Spring+FreeMarker. The real slick part of Spring's integration is that I didn't really need to change any code to support either templating engine. All I had to change was the XML in action-servlet.xml! Very cool!

In the process, I found out that FreeMarker is a bit more strict about the whole MVC thing. With Velocity and JSP, I can remove session variables using $request.session.removeAttribute("varName") and <c:remove var="varName"/>. I agree that doing this isn't very MVC-ish, but I was surprised to find that FreeMarker doesn't even allow this. It allows access to "request attributes", but not the "request" object itself. Of course, this makes it a pain to get the requested URL (request.getRequestURL()) as well.

Now I should explain why I have session variables that I'm removing in the view. The reason is because I save success messages in the session to survive redirects. It just seemed easier (at the time) to remove this variable after I rendered it in the view. Spring doesn't have any out-of-the-box support for success messages (like Struts ActionMessages), so it seems like a reasonable solution. To workaround the the FreeMarker limitation, I decided to add a MessageFilter that grabs messages from the session and puts them into the request. I also added "requestURL" as a request attribute - solving both of the issues I found with FreeMarker, and making my views more MVC-ish.

The one thing I really like about FreeMarker over Velocity is the ability to use JSP Tags in your template. To me, this is very powerful since displaytag and struts menu are my primary reasons for sticking with JSP. After implementing JSP 2.0, Velocity and FreeMarker - it's funny to see how the variable rendering syntax - ${...} - is very similar in all three. Even after implementing Velocity and FreeMarker, I think I'll stick with JSP (2.0) - it just seems a lot more powerful. No limitations if you will.

What's your preference and why? If you're using Velocity or FreeMarker, how do you handle sorting and paging lists? (2004-07-21 00:35:11.0) Permalink Comments [11]

20040719 Monday July 19, 2004

Articles: AOP and JSF with Spring Category: Spring Live

There's been a couple of Spring-related articles published in the last few days. I haven't read them yet, but hopefully bookmarking them here will remind me later:

  • An Introduction to Aspect-Oriented Programming with the Spring Framework, Part 1
  • Put JSF to work: Build a real-world Web application with JavaServer Faces, the Spring Framework, and Hibernate

If you've taken the time to read these, let me know what you think. I hope to read the JSF one in the next few days as I expect to do some Spring + JSF integration this week. In other news, I just converted MyUsers (the sample app in Spring Live) from JSP to Velocity in a couple hours. Hopefully the FreeMarker/SiteMesh/Spring integration will be just as easy.

Being a JSP guy for most of my career - I found it surprising that Velocity doesn't really advocate an error page. It seems to imply you configure a generic 500 page in web.xml, but nothing more. The idea seems to be that you don't need to because most errors are caused by templates. Is this true, or are there ways to grab the exception and print its stack trace onto a page? (2004-07-19 03:10:53.0) Permalink Comments [2]

20040715 Thursday July 15, 2004

Article about AppFuse and Equinox on Category: Spring Live

If you want to learn more about AppFuse and Equinox - checkout my new article on Both apps are designed to ease the process of starting new webapps. This article explains how AppFuse has evolved over the last year and a half and also describes my pleasant experience integrating Spring.

AppFuse AppFuse is not only a jumpstart kit for your web apps; it's also a showcase for integrating technologies like Hibernate, Spring, and Struts. Tutorials exist for integrating these different open source components, but rarely do they give you an application you can walk away with and use to develop your next application. In a sense, AppFuse is a glue that binds open source projects together. When I found Spring, it was a perfect fit, since it was the glue to configure components and loosely couple the different layers of an application. Erik's book might have been the match that lit AppFuse, but Spring is the gasoline that really got it roaring. Spring has vastly simplified how I develop with AppFuse and forced me to follow best practices in J2EE. In short, it's the best tool I've ever used with J2EE. I realize Spring is not the be-all-end-all for J2EE applications -- AppFuse worked fine before I integrated it. However, it helped answer all of my "How should I do ..." questions -- which was a nice relief.

I forgot to mention in this article that Spring ships with some very nice sample apps (i.e. JPetStore) that showcase how to integrate different open source components as well. Thank you to the Spring Developers for helping to make AppFuse what it is today and for producing such a kick-ass framework. (2004-07-15 10:25:49.0) Permalink Comments [0]

20040714 Wednesday July 14, 2004

Should I cover JDO 1.0 or 2.0? Category: Spring Live

In Chapter 7, Persistent Strategies, I'm going to be covering Spring and its JDO support. I was planning on using JPOX, so it's great to see 1.0 was released today. I also noticed they have an alpha release of a JDO 2.0-compliant package. So I'm asking you, dear reader - would you prefer I cover the JDO 1.0 version or JDO 2.0? I'm not sure if Spring cares which version is used - if it does, that'll make the choice for us.

For iBATIS, I am planning on covering 2.0, and Hibernate will be 2.1.x. Hibernate's 3.0 branch is still in development, and they've changed their package names again so Spring doesn't support it (yet). (2004-07-14 15:23:24.0) Permalink Comments [8]

Weblog Archives
Click this photograph for National Geographic's Photo of the Day
Photo of the Day
Spring Logo
+ SourceBeat Weblogs

+ Spring Framework

Spring Live Book
• Raible Designs
• Who is Matt Raible?
Recent Comments
  • [4] Spring Live Reviews and Status
  • [3] SourceBeat Authors have it made
  • [4] [ANN] Spring 1.1 RC1 Released
  • [9] Recommendations for Struts+Spring
  • [3] Managing the source for Spring Live
  • [1] Diffing the changed chapters between releases
  • [11] FreeMarker vs. Velocity
  • [2] Articles: AOP and JSF with Spring
  • [8] Should I cover JDO 1.0 or 2.0?