Preface:

One of the traits of a well-designed application is the efficient handling of crosscutting concerns.  By efficient I mean the application architecture/framework to handle bulk of the crosscutting concerns (such as security, transaction management, logging etc.) and let the individual services concentrate on the business logic. In this blog entry, I discuss one such cross cutting concern and a way to handle it at the framework level.

A few years ago Bruce Tate and Justin Gehtland wrote a book entitled Better, Faster, Lighter Java.  In this book they argue that sometimes a simpler solution is the right answer.   As developers we often become attached to our "Golden Hammer" and try to use it for every purpose.  Large Java EE containers such as Weblogic, JBoss and WebSphere have a place in our toolbox, but sometimes what you need is a simple container which starts quickly and has a small footprint. 

Most substantial iPhone applications require some integration with information stored on a server and almost all enterprise iPhone applications require server integration.  This brief article describes some of the potential solutions for this integration problem and focuses on cataloging tools to solve the problem using a RESTful approach.  Future articles will describe the components in depths; including code samples.

I've been reading up on design patterns lately, particularly those in Core J2EE Patterns. Design patterns are great - they help software architects rely on the collective knowledge and experience gathered from past projects; they also allow designers, developers, and analysts to use a common language.

It occurred to me while flipping through the Core J2EE Patterns that several of them are either outdated or at least their utility has been diminished by advances in JavaEE. (Not to mention that this may mean some of the Core J2EE 'patterns' are too implementation specific and may be better labeled as strategy than pattern).

After seeing a pretty funny blog entry last week on Dart-board Driven Design, I thought I'd finish off a blog post I started on deciding when to use design patterns.

My argument is that the cost of the additional layer of 'pattern' code should be outweighed by the  value the pattern delivers; further, you must evaluate the value when implementing any pattern.

Do you use Spring Portlet MVC? Have you ever noticed the ImplicitModel request parameter in your URL? It looks something like:

org.springframework.web.portlet.mvc.ImplicitModel=true

Well, it’s a Spring Portlet MVC 2.5 feature and I was scratching my head trying to figure out what it does. It’s set by Spring under the covers, so I dug into their source code to understand it and thought I would share.

Jared Richardson spoke at a Richmond Java Users Group meeting I attended last week; his topic was about investing in yourself and your career - what he called career 2.0. At one point during the presentation, he noted that “if you can’t draw something, you don’t understand it”, which motivated me to finish a blog post I started a while back about Spring Portlet MVC.

The goal of this article is to show you how to use pack:tag to optimize the performance of your JBoss Portal theme. I’ve used this approach on a production JBoss Portal 2.6 implementation and tested the approach out in version 2.7.