It’s Only Software

One of the reasons that I think Spring has become so popular in web applications is that there simply hasn’t been another widespread web application stack that (1) is free, (2) is not Java EE, and (3) doesn’t involve JSF.

Wicket (which I’ve written about in passing before) is a great component-based web framework that integrates nicely with Spring (and therefore Hibernate and/or JPA), making it a great choice for a web stack that looks like this:

• Wicket [web tier]
• Spring [transactional / business tier]
• Hibernate [data access tier]

But what other choice is there for a transactional / business layer if you (for whatever reason) don’t want to use Spring?

Fortunately, Dhanji Prasanna has been hard at work on a transactional framework for Guice called warp-persist.

Continue reading “Bleeding Edge Transactional Wicket Web Applications with Warp and Guice”

I use Eclipse 3.3.x and WTP 2.x for most of my web development. Recently, I’ve been using an Eclipse-managed Tomcat 6 server for running and deploying web applications.

I’ve run into the problem several times when “Clean Tomcat Work Directory…” just doesn’t work. Fortunately, you can manually find the deployment directory and blow away your deployed web application – if you know where to look.

For Eclipse-managed Tomcat installs, look in the following directory to find the Tomcat setup for your workspace:

.metadata\.plugins\org.eclipse.wst.server.core\tmp0

You’ll see the usual conf, logs, temp, webapps directories. Your web application is most likely deployed in the “wtpwebapps” directory – look for it there and remove (delete) it. Tomcat will be happy once again.

Note that the “tmp0″ designation may differ depending on how many servers you have configured in your workspace.

Further Reading

Web Tools Platform 2.0 “New & Noteworthy” discusses the use of these new WTP 2.0 features in more detail.

Spring 2.5 RC 2 has been released today, and in addition to the expected bug fixes, this release includes a fully updated version of the venerable Spring MVC Step-by-step tutorial (finally!).

It doesn’t seem that this update has made it to the main springframework.org site yet, so for now the new tutorial is only available as part of the Spring download “spring-framework-2.5-rc2-with-docs.zip” – look in the docs/MVC-step-by-step directory.

Reading through the tutorial, it is definitely much more up-to-date and verbose. Kudos to Thomas, Rick, and Portia on their efforts – this is much better than the Spring 1.x version of this document! Major improvements include:

• Nice screenshots of Eclipse IDE being used to build the various bits of the project.
• Use of convention over configuration in the early stages of the tutorial.
• Coverage of the form taglib introduced in Spring 2.0

Unfortunately, there’s still a couple things that I feel are lacking.

The tutorial seems to have been written without consideration for the new annotation-based configuration introduced in Spring 2.5 – indeed, there’s nary a mention of annotations (except for the ubiquitous @Override) in the entire document. I’m not sure why this is, considering that claims of easier annotation-based configuration have been common in Spring 2.5 announcements and even on the Interface21 blog.

Secondly, while it’s great that an extensive example has been built using Tomcat, in the real world, things are much more complicated. From spending a lot of time helping users in the Web section of the Spring forums, it is obvious that people have trouble setting up Spring on a variety of application servers that are commonly used in production (Weblogic, Websphere, etc.). It would be nice if the common app servers were at least given cursory mention.

Sadly, there’s still no coverage of the use of property editors and how they affect form binding. This is a common source of confusion as well, even among Spring veterans. Even a simple example of binding a Date would save a lot of confusion. Actually, expanding the form section into a couple more complex examples (including select and checkbox tags, please!) would be extremely helpful.

Finally, while it’s not strictly in the purview of Spring to document issues with JSTL, my observation is that a lot of Spring MVC newbies are at the same time first experiencing the pleasure of JSTL. There is a lot of confusion around how to declare taglib references, how webapp version affects taglib declaration, support for different versions of JSTL on different app servers, etc. It would be great if the Spring web documentation (or tutorial) listed common problems related to JSTL (vote for my bug!). This would save hours of frustration by Spring newbies, who simply don’t have the skills (yet) to debug what might be wrong when simple JSTL evaluation doesn’t work on their pages.

Anyway, it’s still nice to see some movement here from the Spring team, and I hope the tutorial continues to be improved and expanded.

While not explicitly highlighted in the Spring 2.5 “What’s New” section, this is a nice little bit to remove a few lines of XML. Spring 2.5 (with the introduction of a new “context:” namespace) takes the common use of a PropertyPlaceholderConfigurer externalizing properties and folds it from the awkward 5-line syntax into a single line.

Before (Spring 2.0 and earlier):

<bean id="propertyConfigurer"
   class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
 <property name="location">
  <value>file:${user.home}/env.properties</value>
 </property>
</bean>

After (Spring 2.5):

<context:property-placeholder location="file:${user.home}/env.properties"/>

The nit-picky will note that you will need to add in the spring-context-2.5.xsd schema reference, however you may be using that already anyway in Spring 2.5 to take advantage of some of the Java-based annotation functionality.

Enjoy!

I recently augmented a Spring-based project to expose some of the Spring-managed beans via JMX. Spring makes this very easy, and even if you’ve never used JMX before, this quick tutorial will let you set up your Spring beans to be viewed (and edited!) through a JMX console.

Continue reading “5 Minute Guide to Spring and JMX”

One feature of Spring 2.5 (previously known as Spring 2.1) that hasn’t gotten a lot of mention is its significantly enhanced unit testing framework, including the brand new org.springframework.test.context package. Rod Johnson mentioned it in his updated article on Spring 2.5 on TheServerSide, but other than that, I tried searching for someone blogging about this subject, and failed – so I figured I’d jot down my impressions about this great improvement.
Continue reading “Spring 2.5 Makes Unit Testing Easy with Annotations”

Since the spammers found my blog long before anyone else, I had enabled high levels of moderation on first using WordPress. This was mainly due to the fact that the only comments I got were links to various online pharmacy sites (hmm, “ph”ish and “ph”armacy do start with the same letters…).

To be more friendly to actual people, and unfriendly to robots, I’ve installed the reCAPTCHA plugin, which I believe should be a good mix of (1) anti-bot, (2) not too annoying or hard to read, and (3) provides something useful (book digitization). If anyone attempts to comment and runs into a problem, do let me know.

Really, this blog (hate the word) is mostly a set of personal notes for myself. If anyone else finds it interesting, great, but if not, at least I won’t forget something interesting

I decided to do a quick investigation of Google’s Guice dependency injection framework. The impetus for this was the recent excitement on TheServerSide regarding Guice vs. Spring, and the ensuing (and always entertaining) TSS discussion thread.

Being a long-time (4+ years) Spring user myself, I decided to download Guice, read through the docs, and have a go at it. I hope this perspective as a long-time Spring user is useful if you’re considering looking at Guice (I admit that Guice has been available for some time, and I’ve just now gotten around to trying to code with it). Craig Walls has an excellent writeup on Guice vs Spring along with a good, detailed example, done in March 2007.

Background

I’ll try to keep this entry at a relatively high level, directed at people who might be considering Guice and where it fits in an application stack vis-a-vis Spring.
Since I’ve recently developed a couple good applications with Spring, I decided a first crack at learning Guice would be to see how I would apply it the simpler of the two projects, and replace our use of Spring 2 with Guice instead. The application in question is a pretty standard Web-based application, using Wicket 1.2, Spring 2, and Hibernate 3.

Guice in a Nutshell

I have to say that the quality of the documentation for Guice is excellent. Bob Lee and the Guice team have done a great job providing a well-written and concise user guide which covers the breadth of Guice through some good examples. Additionally (happily) the Guice crew apparently actually understands how to write quality Javadoc! Take a look at the Javadoc for Binder (one of the key concepts in Guice) for an exquisite example of code documentation. Nice to see in an open-source project!

I was able to come up with some simple examples where I could wire interfaces and implementations together with annotations, without annotations, and perform simple binding of configuration parameters. These were straightforward and intuitive, and the use of method chaining along with the binder DSL made for some very readable, Ruby-esque code.

Guice is definitely a very elegant way of building an application using good DI principles. I tried very hard to suspend my prior bias towards Spring-style XML configuration, which can get very hairy if you have a project with hundreds or thousands of beans spread across multiple XML files.

I could see Guice working very well in a strictly component-based environment where code is widely shared across applications, with very loose coupling and good attention to API contracts — someplace like Google, for instance.

Guice and the “Real World”

Therein lies the problem, however. I am an application developer by trade, and those applications have generally been web-based, and involve the typical 3 tiers – web, business, and data. Guice shines at the business tier, but quite literally has almost nothing to address the inherent complexities of managing dependencies across tiers.

Guice provides very short shrift to the web tier, giving a modicum of session- and request-scoped bindings, with (shockingly!) almost no formal documentation. No examples exist on the Guice site to provide the newbie with any clue how to tie it into a real-world application. Guice relies on “viral” dependency injection – in order to get a Guice-injected resource, you need access to the actual Injector object. The common suggestion for this is to stuff this reference in a static or ThreadLocal. Unfortunately, Guice doesn’t inherently provide you with a canned way to do this – it’s left as an exercise to the reader.

The “exercise to the reader” issue is one you’ll run across often, and I think is a testament to the laser focus of the Guice framework. Guice is really intended to be (only?) a great dependency injection and management framework, but it needs a lot of integration with other bits in your stack to make it work.

In my test case (Wicket / Spring / Hibernate-based application), I had some amount of success.

Wicket 1.3 beta 4 offers built-in support for Guice injections into components, and after going through the well-documented Wicket 1.2 to 1.3 upgrade pain, it “just worked” as easily as the Wicket – Spring integration does. This is a result of Alastair’s stellar work on the Wicket project – great job!

Unfortunately, the data tier proved to be more problematic. Although there are various suggestions about design patterns on the Guice newgroups, including copious feedback from Bob and the Guice team, there’s not yet a good choice for integrating Guice with your data tier (ORM or JDBC layer). A project that looks promising is the warp-persist module from Dhanji Prasana, which integrates Guice and annotations around a transactional framework that can itself wrap Hibernate or JPA. I plan on evaluating this very soon, although at this point it is in heavy development, and as such suitable only for development environments. One of the reason that I am excited about the warp-persist project is that the (only?) author, Dhanji, is very active on the Guice newgroups, as well as providing some excellent Warp-related articles on his blog.

So, if you were to try to build a web application stack with Guice, it might look like this:

• Web Tier: Wicket
• Business Tier: Guice / Warp-persist
• Data Tier: JPA

This certainly seems reasonable, and I bet around the time that Warp gets more stable, and Guice 1.1 (or 2.0?) is released, I’ll start getting good questions from folks who want to use it.

… and Spring …

Contrast the discussion of the previous section with Spring, which has great appeal to architects and business types, because it takes the “kitchen sink” approach and literally can manage your whole top two tiers (web and business/service), down through transaction management and into the data tier. For architects or technical designers, Spring is still a pretty safe bet to build an application stack with, simply because it does almost everything you need already.

Trying to convert an existing application which uses broad features of Spring into an application based solely on Guice is basically nonsensical – if you’ve invested a lot in the breadth of Spring, you’re going to be very disappointed in the lack of breadth available in Guice.

Even simple things that Spring does, such as externalizing property bindings into properties files (a must for applications that are configured per environment, or per customer), are roll-your-own in Guice. Although Guice may be a more elegant way to tie dependencies together, you’ll find that it requires a lot of hard thinking on how to “do the right thing,” a task which many pragmatic developers will have a hard time with.

Which should you use?

As with many other things, the right tool for the right job. I could see Guice being ideal for non-web based applications, and generally promoting good design principles. It is extremely lightweight, and as such could be used in client-side apps launched via Java Web Start. Definitely worth paying attention to as it, and the community around it, develops.

(The curious reader may wonder why I haven’t touched the XML-vs-java configuration argument. I will explore that in a later article when I have time to review the changes and enhancements in Spring 2.5, nee Spring 2.1!)

Thanks for reading!