On the Auto Bailout
Since it just makes good sense to understand a problem before we dole out the cash, let's ask ourselves a question before we go spending (quite a bit) of our tax dollars.
Why are the U.S. auto makers in a crunch? Of course our economy isn't great and that's one reason, but you must still ask "Why are they doing worse relatively compared to the foreign competition?"
A lot of reasons: Reliability rankings. Worthless bureaucratic unions. Poor management. Inability to adapt to consumer demand, inferior engineering discipline, etc, etc, etc.
Each one of these reasons, and more, are worth their own posts entirely, but since I don't have time for that at the moment, let's continue.
So, we've identified why they are suffering. We've identified a problem. Now let's come up with a solution.
Let's think of what the auto bailout is supposed to do: give cash to auto manufacturers, which affords them a liquid capital cushion, which in turns enables them to keep people employed. Keeping people employed is good for the economy - they can go out and buy things and keep the money cycle flowing.
But what happens a year from now when the money has run out?
They'll still be producing inferior cars. The worthless unions will still exist. Management for the entire industry won't be likely to change that fast. They won't be able to engineer new cars that meet consumer demand that quickly.
We as a nation will be in even more debt and we'll still have that big glaring economic problem staring us in the face. This is typical Congressional behavior, "Let's spend money to put a Band-Aid on the problem and hope it goes away. Never mind that we're not addressing the root cause of the problem...". That's Congress' solution. A Band-Aid that solves nothing.
No one is addressing the fundamental problem - that U.S. auto manufacturers produce an inferior product under an inferior system. In a capitalistic society, as ours clearly is, the most efficient entities (corporations, processes) 'win'. It is cut throat. If you can't compete, you get swallowed up. This is what is happening to the U.S. auto manufacturers. They're imploding under their own inefficient weight. The rules of capitalism are prevailing.
So, any attempt to give them money without fixing the problems is completely futile. It's a waste of time, energy, and our hard-earned money. The problem won't go away, and we'll be further in debt.
I encourage you to contact your Senator and U.S. Representative and make known your feelings. Don't stand for a 'band-aid'. Demand more!
This nicely sums up the situation:
Ki Ken Tai Ichi (気剣体一)
As part of my Kendo Shodan （first degree black belt) examination （剣道の初段の審査）, I had to answer a question regarding one of Budo's fundamental principles - that of 'ki ken tai ichi' I've included my answer here in hopes that it helps people better understand Budo in general.
Ki-ken-tai-ichi, from the Japanese kanji 気剣体一, describes the condition when all essential elements of a strike are unified in a single instant culminating in the perfect strike. The resulting strike, called the yuko-datotsu , or 有効打突, “valid strike”, is a goal all Budoka should strive to achieve.
Dissecting the Kanji into sub-parts can give a better understanding of the term’s meaning.
気, ‘ki’, is the kanji representing “spirt” or “energy”. In the context of ki-ken-tai-ichi, it represents the Budoka’s mental assertiveness and instinctive focus that both initiates and finalizes the strike.
剣, ‘ken’, is the kanji for “sword”. In ki-ken-tai-ichi it is naturally the actual instrument that manifests the mental (internal) and physical (external) intentions of the Budoka when executing a strike. As such, it should be regarded as an extension of the Budoka, not a separate disconnected element.
体, ‘tai’, is the kanji for “body”. In context, this represents the physical element of the Budoka’s intent – his body, the mechanism by which the mind’s intentions are executed resulting in the end goal.
一, ‘ichi’, the kanji for the number one (1). This is added to signify that the ‘ki’, ‘ken’, and ‘tai’ should not be considered separate elements at the moment of impact, but a single unified construct.
The final kanji, ‘ichi’ is the most important. It means that all three elements, the spirit, sword, and body must be realized as a single cohesive element if the resulting strike is to be considered ideal. The ability to obtain ki-ken-tai-ichi consistently is a goal of Budoka of all ranks.
Maven 2 vs Ant+Ivy: Our selection process
This is an old post. I have long since moved on to Maven as described here
The JSecurity team had a recent discussion on whether or not to use Maven 2 or Ant+Ivy moving forward. At the end of the day, I didn't really care that much about which system we used, but I had three requirements:
- JSecurity releases must be pushed to the Maven 2 repository for easy access by both Maven and Ivy users
- When executing a build, I want versioned dependencies automatically resolved and downloaded for the builder. This way things are 'hands off' and the JSecurity release .zip file doesn't have to be 14 megs. Excluding dependencies would drop it to maybe 3 megs - much nicer.
- I don't want to manage builds much at all. Anything that takes my time away from JSecurity coding or writing documentation is less than ideal. Whatever system we chose, I wanted to spend maybe 2 or 3 days at the most configuring it and then just leave it alone (but still have it be clean and flexible enough for inevitable changes down the road).
What was the outcome? We ended up choosing Ant+Ivy, but I've outlined how we came to our conclusions based on the above 3 requirements for anyone that might find this useful when making their choice. This represents why it was a good choice for us, and may not be the same reasons for you. Everyone is different - choose what works for you based on your needs and desires.
Satisfying requirements:
Point #1 is handled trivially by both frameworks, so no need to speak of that further.
Point #2 is is handled by both frameworks without any problems, but that's not the whole story: With further investigation, we found Ivy's dependency resolution process to be more elegant, which had great appeal to us after we found out about it:
For any given dependency, both Maven and Ivy allow you to also control your dependencies' dependencies that are downloaded. These are called transitive dependencies. For example, if your project requires hibernate to build, and hibernate requires JTA to build, does that also mean that your project needs JTA to build? In most cases this is not the case, and either framework will allow you to do excludes as necessary.
But Ivy has something more that turns out to be very powerful, something they call "configurations". Configuration xml snippets in the ivy.xml file are more or less what I call dependency "views". For example, one configuration entry (view) can mean "for a hibernate test, only require a, b and c jars", or a "for minimal runtime requirements, only require x and y jars." Here's the best part - other projects can depend on these views so they only download what they absolutely requre, allowing configuration of transitive dependencies across projects. Extremely powerful, much cleaner, and arguably 'more correct' for proper software configuration management.
Another area related to point #2 where Ivy won out for our team is that only Ant is required, which is pretty much ubiquitous in all Java environments. Maven not so much. Ivy is even less so, but our plain 'ol ant script will download Ivy for you if you don't already have it, make ant aware of it, and then kick off Ivy as normal. NO software installation beyond Ant. That is just fantastic as far as I'm concerned, since we don't want to force Maven on end-users who want to build the project. You'd be surprised at how something like that can make or break potential users. This all goes back to the lowest barrier of entry for people who want to use our project. This stuff matters to us.
Point #3: Maven actually won out here because of its black magic. It is easier to set up a Maven project for starters because it has so much built-in to it, whereas a similar Ant+Ivy setup requires plain 'ol Ant setup + knowledge of how to incorporate Ivy. It might take a day or two to set up Ant+Ivy depending on your familiarity with Ant.
Although this is a powerful benefit of Maven, I feel it is beneficial for only small or simple projects. If you have a moderately complicated build environment, or one in which any level of specific customization is required, its far easier to do with Ant instead of fighting with Maven's black magic quirks. Once you spend the initial day or two getting Ant+Ivy to just work, you rarely have to touch it again.
Add in the big ant benefits of macrodef and import and you quickly get an 'OO-like" build approximating what Maven can do. Yes it requires more effort, but when you can do what you want, whenever you want, well, I enjoy that piece of mind. I don't want to fight with my build system when I need something - I want it to adapt to my needs.
In the end, it took me a couple of hours to set up Ivy and play with it and read the documentation and and continue to play with my ivy.xml "configurations" (views). But, now it is smooth sailing. I'm loving Ivy, and I'm glad that we made the choice we did.
- Les
Groovy Examples
Groovy is by far my favorite scripting language, since it leverages and integrates with all the Java stuff I use (applications, tools, server software, etc). It is just as expressive and powerful as Ruby, Python, etc., but feels a little simpler or cleaner, depending on the comparison.
Here are two fantastic resources in the 'Cookbook' fashion, showing how to do many useful things with Groovy:
The Groovy website Cookbook
PLEAC's Groovy Cookbook - a Cookbook similar to Perl's original Cookbook.
Subversion Recovery Without a Backup
This post outlines how to re-create a subversion repository after a total failure or loss (disk overwritten, disk crash, accidentally deleted, etc) when you have no repository backups and only developers' working copies. If you've lost your SVN server and have no backups of your repository, and you don't want to do manual per-file copying from the old working copy to a new working copy, this is your only option - you have no other choice.
Background:
At my current client's site, we were using a makeshift Subversion repository (one of the best RCSs available) to overcome problems with Clear Case, aka THE WORST REVISION CONTROL SYSTEM EVER. God how I despise Clear Case, that eternally flawed disgusting dung substitute attempting to be an RCS. Just to be clear, in case you might have misunderstood me, I'll restate: Subversion is amazing, Clear Case only wishes to approach the beneficial status of say, fungus on the wall of an abandoned Vietcong prison.
Anyway, we set up Subversion to use as our primary repository, but unfortunately, didn't set up a nightly backup process to a different machine. That bastard Murphy struck: after only 2 weeks of using this box, the hard drive failed and we lost the repository in its entirety. Lesson learned - always always backup your SVN repo to another machine nightly. Continuing on...
Naturally the developers on the team all had our local working copies, so we still had all of our code and nothing was permanently lost. Now if the original problem were a mere disk failure and no one had changed their working copies since the last SVN update, this would be an easy problem to solve: just create a new SVN repository, import only one of the working copies, and everyone then does a fresh checkout of the new repository and continues on their merry way.
But as Murphy would have it of course, we all had modified our local working copies for about a day and a half after the hard drive crash. We couldn't just kill productivity until the new one was rebuilt over the next two days. So we kept working and subsequently our working copies became out of sync with each other.
Solution (nearly identical to this email thread, but elaborated):
When the new Subversion server was back online, I performed an svn export of my existing local working copy, which produced a 'clean' directory tree. I then svn imported it into a brand new repository on the new Subversion server, creating version 1. At this point it is worth mentioning that my existing working copy before export was at version 395. After importing the clean 'exported' tree, the new repo will start with version 1. Forget about trying to recover revision history from your existing working copy after a total repo loss - its not possible - versioned changes related to the old repo are lost forever.
So although we had to start over at version 1 again (not as ideal), at least we had a proper repository again with no significant code loss.
But what about the other developers who had made changes the last two days? They need to get their changes into the new repository.
You CANNOT do this with say an 'svn merge' or 'svn switch' (even with --relocate - it won't work). If you tried to even get the log from within a working copy from the old repository, you'd see something like this:
> svn log svn: No such revision 396
So, how do you do a proper merge of your old-repository-but-latest-code-working-copy into the newly-checked-out-working-copy?
The only way is old-school diff and patch programs. Trust me, there is not another way, I researched for hours so you don't have to. Anyway, here's how to do it. Each developer had to run the following steps:
If you're running Windows, you can still execute the following steps, but you'll have to download and install GNU DiffUtils and Patch for Windows:
- Download and install GNU's Windows DiffUtils
- Download and install GNU's Windows Patch
- After you run both setup programs, they will be installed into
C:\Program Files\GnuWin32\bin. Open upStart > Control Panel > System > (Advanced Tab) > Environment Variables. Add this directory to the front of your%PATH%environment variable. This will allow you to calldiffandpatchon the command line.
Ok, now for *nix users and Windows users who have completed the above 3 steps:
- Check out a new working copy of the brand new SVN repository to a directory different than your current working copy.
For example, on my machine, my ‘old’ failed-repo-working-copy is in
~/projects/projectName-old/trunk. My new checkout was made to~/projects/projectName-new/trunk. svn exportthe failed-repo-working-copy to a temp dir. When this was completed, I had the following directory:~/projects/projectName-old-export/trunksvn exportthe new working copy that you just checked out a second ago. When I was done I had a directory:~/projects/projectName-new-export/trunkcdto your new working copy (e.g.~/projects/projectName-new/trunk) anddiffandpatchthis working copy:> cd new_WC_dir > diff -ru new_WC_export_dir old_WC_export_dir | patch –p0
For example, this is what I did:
> cd ~/projects/projectName-new/trunk > diff –ru ~/projects/projectName-new-export/trunk ~/projects/projectName-old-export/trunk | patch -p0
When this command was finished, I had a bunch of lines printed to the console
patching file …- Commit your new working copy back to the new subversion server. This is just a normal commit at the root of the new working copy e.g.
> cd ~/projects/projectName-new/trunk > svn ci -m "Committing out-of-sync work resulting from hard drive crash"
You can then check-out/commit as normal from this point onwards.
I strongly recommend deleting all the other directories and renaming the existing 'new' directory to just the project name to avoid confusion moving forward:
e.g.
> cd ~/projects > mv projectName-new projectName > rm -rf projectName-new-export projectName-old-export projectName-old
Cheers,
Les
Cool Utada Hikaru story
So I was at work today, hammering away on the keyboard, when out of nowhere, as if coming through faint elevator speakers off in the distance, I heard Hiki's first song on her latest Ultra Blue album, entitled "This is Love".
I thought to myself, "Man, am I hearing things? What the hell? I know this can't be coming from the sound-deadening cubicles of a large Southern corporation...".
But I got up and searched for a bit. About 5 cubes away is someone showing off his iPhone to a fellow co-worker. When I arrived, there wasn't any music playing, but I asked anyway. "I'm sorry to interrupt, but was someone here playing Utada Hikaru?"
They looked at me a bit funny at first, but then the guy holding the phone thought a second and said, "Oh, this?", and played the song.
I was like "Yeah! That's it! I love that girl..."
He said, "Oh yeah, its a song my daughter put on to my iPhone - she's into Japanese things."
Then I proceeded to tell them about my interest in Japanese culture, having been there once, etc. It was kind of cool.
But mostly I was really surprised to hear that song in this building. It was bizarre, since most people in the South have no clue who Hiki is. (My future wife just to clarify for you in case you don't know) 
Good stuff
Root Persistent Class for ORM Hierarchies (Hibernate, et. al.)
Ok, I'm about to divulge to the world one of my little programming gems - something I've used on every single project for almost the last 4 years now. It is very easily translated to any other OO language as well, especially C# for the .NET/Hibernate.NET folks.
I haven't been keeping it secret or anything, I guess I just never took the time to write it out for general public. So when someone reading my blog asked to see the source for it, I figured now is as good a time as any to write about it.
It is a root/base class from which all my persistent Classes extend. To put it another way, if I have Java instances that I need to store to a database through Hibernate or some other EIS API, every one of those instance Classes extend from this base class (either directly or indirectly in an OO hierarchy). Every entity in every persistent class hierarchy I've used in the last 4 years has it as its hierarchy root - it is versatile and resilient
Now, if you've used Hibernate much before, you'll realize this isn't the world's biggest secret - most people do something similar. Its a great idea. I'm just making mine available to the world in case there are those that haven't done something similar yet, or if those who have just want to see how I do things.
What is this class called? I call it Entity. In Object-Relational Mapping circles, the word Entity often comes up in the context of object persistence discussions - "Persistent Object", "Persistent Entity", "Base Persistent Object", etc. I personally think "Entity" is elegantly succinct, so I stuck with it.
Before going on to the code, I just want to clarify my Entity class a little bit. It is not an implementation of what many call the "Active Record design pattern". This means this base entity class doesn't know how to persist or delete itself via any save() or delete() methods.
I'm a firm believer in keeping persistence logic code out of my domain model to prevent the chance of polluting the rest of my application with those APIs (it goes beyond API pollution too - google the principal of "Low Coupling, High Cohesion" for more info). Anyway, and I relegate all such logic to DAO implementations and all of my domain classes remain nice and clean.
Ok, so now that point is settled, here's my oh-so-yummy-and-incredibly-useful Entity class:
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import java.io.Serializable;
/**
* Root parent class for all persistent object entities.
*
* <strong>NOTE:</strong> Subclasses should <em>always</em> provide a unique
* onEquals() and hashCode() implementation and these should not use
* the id() property - i.e. always keep in mind the subclass' 'business keys'
* when implementing those methods.
*
* @author Les Hazlewood
*/
public abstract class Entity implements Identifiable, Serializable, Cloneable {
protected transient final Log log = LogFactory.getLog(getClass());
/**
* RDBMS Primary key, aka 'surrogate key'. Long surrogate keys are best
* for RDBMS performance (for many reasons that can't be expanded on here)
* But, every single table should _always_ have a 'business key' - a unique
* constraint across one or more columns that guarantee row duplicates will
* never occur. Null value means the object hasn't been persisted to the RDBMS
*/
protected Long id = null;
/**
* Used for optimistic locking to ensure two threads (even across different machines)
* don't simultaneously overwrite entity state - not necessarily used by all subclasses.
* Pretty much required if in a high-concurrency environment and/or if using distributed
* caching in a cluster. It (and its corresponding mutator methods) is not called
* 'version' to prevent eliminating that name from subclasses should the business
* domain naming conventions require it. Also 'entityVersion' is self-documenting
* and leaves little room for incorrect interpretation.
*/
protected int entityVersion = -1;
public Entity() {
}
public Long getId() {
return this.id;
}
/**
* Should <em>never</em> be called directly. Only via Hibernate or other EIS framework, since
* they get the ID from the RDBMS directly.
*
* This method can be removed entirely if the EIS framework supports setting the ID property
* directly (e.g. through reflection). Hibernate does support this, it is called 'property access'.
*/
public void setId(Long id) {
this.id = id;
}
public int getEntityVersion() {
return this.entityVersion;
}
/**
* For the same reasons as the setId() method, this should only be called by a
* framework and never directly. Can be removed if the framework supports property access.
*/
public void setEntityVersion(int entityVersion) {
this.entityVersion = entityVersion;
}
/**
* This method is declared final and does a lot of performance optimization:
*
* It delegates the actual "equals" check to subclasses via the onEquals method, but
* it will only do so if the object for equality comparison is
*
* <ol>
* <li>not the same memory location as the current object (fast sanity check)</li>
* <li>of type Entity or one of its subclasses</li>
* <li>Does not have the same id() property</li>
* </ol>
*
* #3 is important: this is because if two different entities have the ID property
* already populated, then they have already been inserted in the database, and
* because of unique constraints on the database (i.e. your 'business key'), you
* can <em>guarantee</em> that the objects are not the same and there is no need
* to incur attribute-based comparisons for equals() checks.
*
* This little technique is a massive performance improvement given the number of times
* equals checks happen in most applications.
*/
public final boolean equals(Object o) {
if (o == this) {
return true;
}
if (o instanceof Entity) {
Entity e = (Entity) o;
Long thisId = getId();
Long otherId = e.getId();
if (thisId != null && otherId != null) {
return thisId.equals(otherId) &&
getClass().isAssignableFrom(e.getClass());
} else {
return onEquals(e);
}
}
return false;
}
/**
* Subclasses must do an equals comparison based on business keys here.
*/
public abstract boolean onEquals(Entity e);
public abstract int hashCode();
/**
* If children classes override they must always call super.clone() to get the object
* with which they manipulate further to clone remaining attributes. Never acquire
* the cloned object directly via 'new' operator (this is true regardless of this Entity
* class or not).
*/
@Override
@SuppressWarnings({"CloneDoesntDeclareCloneNotSupportedException"})
public Object clone() {
Entity e;
try {
e = (Entity) super.clone();
} catch (CloneNotSupportedException neverHappens) {
// Should _never_ happen since this class is Cloneable and
// a direct subclass of Object
throw new InternalError("Unable to clone object of type [" + getClass().getName() + "]");
}
e.setId(null);
e.setEntityVersion(-1);
return e;
}
/**
* Returns a StringBuffer representing the toString function of the class implementation. This
* should be overridden by all children classes using <tt>super.toStringBuffer()</tt> as the
* base, adding properties to the returned StringBuffer.
*
* @return a <tt>StringBuffer</tt> reperesenting the <tt>toString</tt> value of this object.
*/
public StringBuffer toStringBuffer() {
StringBuffer sb = new StringBuffer();
sb.append("id=").append(getId());
return sb;
}
/**
* Returns toStringBuffer().toString(). Declared as 'final' to require subclasses to override
* the {@link #toStringBuffer()} method, a cleaner and better performing mechanism for toString();
*
* @return toStringBuffer().toString()
*/
public final String toString() {
return toStringBuffer().toString();
}
}
You'll notice that the Entity class also implements Identifiable, which is nothing more than this:
/**
* @author Les Hazlewood
*/
public interface Identifiable {
Long getId();
}
This doesn't look too useful, but I have another interface that subclasses ('sub interfaces'?) it:
/**
* @author Les Hazlewood
*/
public interface Referenceable extends Identifiable {
String getLabel();
}
Referenceable is particularly useful in GUI/web code where you might want to present a list of options to the user, and the list-generation code only cares about IDs and readable strings to present to the user. For example, a drop-down/select box:
$referenceable.label
The list generation code doesn't care if the collection it is processing has User elements, or EmailAddress elements, or anything else. Ahh, the beauty of polymorphism
Anyway, I hope you find this Entity class as useful as I have - it is the staple by which I develop all of my domain models in Java.
Cheers,
Les
Configuration-hell remedy with Singleton injection – DON'T do it
So, I just finished reading this blog post about Spring configuration advocating static getInstance() methods in some places in your code to reduce the amount of Spring xml config. Since I posted a reply on that blog, and the author would probably be inclined to moderate my entry and delete it because I directly oppose his position, I've reposted it here for the benefit of others to read.
THAT POST ADVOCATES POOR ARCHITECTURE. IGNORE IT.
If you're relatively new to the Spring framework, ignore the recommendations in that post entirely - you'll be saving yourself a _lot_ of pain in your software architecture.
Basically, here's my reply:
This is a really bad idea and is exactly what Spring pojo-based Dependency Injection was created to avoid - to replace the Service Locator pattern. What you're providing in a static getInstance() call is essentially a type-specific Service Locator.
Statics are evil - they're inherently non-OO and usually encourage poor programming practices, especially the proliferation of unnecessary functional programming in an OO language. They should only be used to overcome poor programming situations outside of your control - i.e. a tool to use in an extremely limited basis only when you can't use something else.
And although what you describe might make your life easier in the immediate sense, it significantly complicates it in other ways. How, for example, would you unit test your code properly without introducing dependencies not required for the test? Cleaner instance-level DI allows you do do things such as creating mock objects and anonymous inner classes for testing that is not possible with static singletons or where you would have to change a lot of code.
If you want to make your life easy, use autowiring - that's exactly why it was created. The new Spring 2.0 XML namespaces also simplify things greatly, reducing XML config. And, with IDEs like Eclipse and IntelliJ IDEA that actually can traverse, manage, and refactor the XML spring files for you, the "XML Hell" argument for using Static singletons, especially when your own code suffers greatly in flexibility, is not really an issue.
Bottom line - never let laziness dictate your software architecture (especially when similar alternatives like autowiring exist), and stick with the pragmatic, well-thought and proven truly Object-Oriented solution.
I just thought it important to raise the issue on this for anybody reading this blog entry, especially those relatively new to Spring. What is mentioned is _not_ a good idea for 99% of cases, and the less-experienced Spring folks shouldn't be led down a dangerous path. It could introduce really bad habits that would hurt you later on.
Consistent Cache Configuration: Spring, Hibernate, EhCache, Shiro, et. al.
Have you ever wanted to use caching in your Spring/Hibernate application beyond just supporting Hibernate's 2nd-level cache?
If you know what a Hibernate 2nd-level cache is, you really know how huge its performance benefits are. Wouldn't it be useful to utilize caching for other things in your application? Even if you don't explicitly use a caching API in your app, you still might already be using caching without knowing it - other open source frameworks in addition to Hibernate utilize caching internally for the same performance benefits.
This article explains how to achieve the following:
1) I know I'm going to utilize caching for Hibernate's 2nd-level cache, but I want to enable that same caching support to other libraries and frameworks that might need it. It would also nice to have if I ever need to use it in my own application code directly.
2) My application is Spring-configured, so I want to configure that caching support in Spring like everything else and then have all the frameworks/libraries, including Hibernate, to use these Spring-configured cache beans.
Unfortunately Hibernate makes this a pain to do.
Hibernate uses something called a CacheProvider to support its 2nd-level cache. A Hibernate SessionFactory uses a single CacheProvider to maintain/manage the individual Cache instances used by the 2nd-level cache.
Now here's the problem: This CacheProvider is instantiated by Hibernate based on text configuration properties specified to the SessionFactory. When the SessionFactory starts up, it reads these properties, finds the one called hibernate.cache.provider_class which specifies a fully-qualified class name of the CacheProvider implementation, and creates a new instance of that class via reflection. It then uses that instance from then on to manage the Cache instances it needs.
For existing spring configs, here is a simplified example (note the 2nd hibernate property):
hibernate.dialect = org.hibernate.dialect.MySQL5InnoDBDialect
hibernate.cache.provider_class = net.sf.ehcache.hibernate.EhCacheProvider
Why is this a problem? Because you can't easily configure your CacheProvider instance yourself and then just tell the SessionFactory to use it. The SessionFactory interface and its default implementation do not have setter methods that would allow you to do so. This means you can't use Dependency-Injection to set the CacheProvider instance on the Hibernate SessionFactory in Spring or any other DI microcontainer.
This is a problem for me too. The scenario that prompted this article happens to me quite a bit - I use Hibernate plus other libraries that benefit from caching. My own open-source project, Apache Shiro, can use caching to greatly speed up security checks. When I use Hibernate and Shiro in the same application, I want both frameworks to use the same underlying cache infrastructure. And although Shiro supports DI for its cache support, Hibernate does not, which means I have to jump through hoops to get Hibernate to play nice.
Where does Ehcache come in to this? Well, Ehcache is one of the more well-known and stable open-source caching solution for enterprise applications. It is stable and has a long history, it is extremely efficient with goodies like smart multi-threading under the hood, and now with Ehcache 1.3+, supports multicast distributed caching in a cluster - a huge benefit in enterprise apps. Basically, for open-source options, it is one of the best you can get. Cheers to Greg Luck for creating and supporting this great library (Another wonderful Open Source alternative is TerraCotta, take a look at that too).
So, in this particular example, I'm using EhCache but I also want to use it not just for Hibernate, but for Shiro and everything else that could use a Cache. And until now, I've been using Ehcache as Hibernate's cache provider using the aforementioned text property. Hibernate would create an instance of EhCacheProvider and use it internally. Basically this EhCacheProvider implementation is a wrapper around EhCache's own API of a CacheManager.
The CacheManager is really what I want to configure in Spring. Typically it is good practice and much easier to specify a single CacheManager for an application, which uses a single ehcache.xml file for all configuration. Then you can use this one ehcache.xml file for your Hibernate cache configuration, as well as for any other library that would use EhCache under the hood.
So, since you can't inject a CacheManager into Hibernate's SessionFactory, how do you do this in Spring?
Well, Since Hibernate instantiates the CacheProvider itself, and we can't inject anything, our only option left is via static memory. Blech, I know - I don't like statics any more than you do, but don't worry - it is _only_ used as a mechanism to make Hibernate play nice and its never used anywhere else in your config or application code.
*Note that static memory will only allow a single CacheManager to be used across the entire VM, so if you need more than one Hibernate SessionFactory, each with its own separate cache configs, you'll need to do more trickery (maybe 2 static fields? one per SessionFactory? You'll know more about your app than I do, so I'll leave how to do that to you. But you can use this the following technique and expand on it for your environment).
Let's get to the code, its only one class. You'll create your own CacheProvider implementation to statically reference a CacheManager instance. The CacheManager instance will be configured in Spring, and we'll get to that in a bit. Here's the CacheProvider implementation:
package com.leshazlewood.hibernate;
import net.sf.ehcache.CacheManager;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.hibernate.cache.Cache;
import org.hibernate.cache.CacheException;
import org.hibernate.cache.CacheProvider;
import org.hibernate.cache.Timestamper;
import java.util.Properties;
/**
* @author Les Hazlewood
*/
public class ExternalEhCacheProvider implements CacheProvider {
protected transient final Log log = LogFactory.getLog(getClass());
private static CacheManager cacheManager = null;
/**
* This is the method that is called by an external framework (e.g. Spring) to set the
* constructed CacheManager for all instances of this class. Therefore, when
* Hibernate instantiates this class, the previously statically injected CacheManager
* will be used for all hibernate calls to build caches.
* @param cacheManager the CacheManager instance to use for a HibernateSession factory using
* this class as its cache.provider_class.
*/
public static void setCacheManager(CacheManager cacheManager) {
ExternalEhCacheProvider.cacheManager = cacheManager;
}
public Cache buildCache(String name, Properties properties) throws CacheException {
try {
net.sf.ehcache.Ehcache cache = cacheManager.getEhcache(name);
if (cache == null) {
if ( log.isWarnEnabled() ) {
log.warn( "Unable to find EHCache configuration for cache named [" + name + "]. Using defaults.");
}
cacheManager.addCache( name );
cache = cacheManager.getEhcache(name);
if (log.isDebugEnabled()) {
log.debug("Started EHCache region '" + name + "'");
}
}
return new net.sf.ehcache.hibernate.EhCache(cache);
} catch (net.sf.ehcache.CacheException e) {
throw new CacheException(e);
}
}
public long nextTimestamp() {
return Timestamper.next();
}
public void start(Properties properties) throws CacheException {
//ignored, CacheManager lifecycle handled by the IoC container
}
public void stop() {
//ignored, CacheManager lifecycle handled by the IoC container
}
public boolean isMinimalPutsEnabledByDefault() {
return false;
}
}
Ok, now that you have this class, what do you do with it? Well the first thing is to change your hibernate.cache.provider_class value to now be com.leshazlewood.hibernate.ExternalEhCacheProvider in your Hibernate SessionFactory bean definition. Then you want to define your CacheManager instance as a bean in your Spring config. Next you want to tell this CacheProvider implementation to use that instance when Hibernate needs to use caching functions.
We do that via a cool little Spring trick - by using the MethodInvokingFactoryBean. Basically this bean will call a static method at application startup with specified method arguments. Its a handy little tool that we can use to statically call the setter method that makes the CacheProvider work:
So the above spring config says: At application startup, create the CacheManager instance named 'ehcacheCacheManager' and then inject it into the ExternalEhCacheProvider via that class's 'setCacheManager' static method.
But are we finished?
Well, not quite. We have one piece of cleanup work to do.
The experienced Spring folks will recognize that there can possibly be a race condition with our Hibernate SessionFactory and CacheManager/CacheProvider definitions. Yes, our Spring-configured CacheManager instance will be created and injected into the ExternalEhCacheProvider class correctly, and our Hibernate SessionFactory bean instance will be created correctly. But, what if the Hibernate SessionFactory tries to use a ExternalEhCacheProvider instance before it is ready to be used? (i.e. before the static CacheManager property has been injected?)
To prevent this race condition and guarantee that the ExternalEhCacheProvider's internal CacheManager instance is set so it is available when the Hibernate SessionFactory needs it, we use the spring bean 'depends-on' attribute in our SessionFactory definition:
depends-on="cacheProviderCacheManagerInjector">
hibernate.dialect = org.hibernate.dialect.MySQL5InnoDBDialect
hibernate.cache.provider_class = com.leshazlewood.hibernate.ExternalEhCacheProvider
So, although our Hibernate SessionFactory bean doesn't actually use the CacheManager as a property - otherwise this whole article would be pointless 
- we force it to wait until the cacheProviderCacheManagerInjector bean has done its work before we allow it to initialize.
We make the 'depends-on' attribute point to this injector (MethodInvokingFactoryBean) instance specifically (as opposed to the ehcacheCacheManager bean) because we care that it is not only created, but also injected too.
There. Now we're done.
Now when the Hibernate SessionFactory bean starts up and creates its hibernate.cache.provider_class instance, we can rest assured that it will access our Spring-configured CacheManager.
And, you'll be able to use that same Spring-configured 'ehcacheCacheManager' bean and inject it into Shiro, or any other framework that supports simple Dependency Injection. Because this bean is an application singleton and uses a single config file, now all of your caching config across the entire application is easily manged from the same location - very convenient.
Have fun!
Integrating Spring with the ThinWire Rich Internet Application framework
ThinWire is an amazing Rich Internet Application (RIA) framework that caters to Java developers. The concept is extremely similar to other frameworks out there such as the Google Web Toolkit (GWT), ZK, Echo2, wingS, Flex and some others. Lets just say that most people who use ThinWire and these other frameworks can increase productivity 10-fold for web-based applications - they're that big of a deal.
After quite a lengthy period of evaluation of all of these frameworks, I chose ThinWire as my current favorite. The reasons why and my selection criteria are worth an entirely different post - there's a lot to say there. But, the purpose of this entry is to show folks how to integrate Spring (and all that it provides, such as Hibernate utilities, et. al.) with ThinWire. There's not any real documentation on how to do that cleanly, and ThinWire doesn't support it directly yet (maybe they will soon?), so I hope to fill the gap here.
So for the remainder of this article, I assume you know what Spring is and have used it in actual application before. I also assume that you have at least seen what ThinWire is and have looked at its API just a little, even if you haven't used it yet. Anyway, lets get started.
ThinWire's biggest appeal is that you program the full web-app in 100% Java, just like Swing (but its not Swing), and never worry about JSPs, CSS, template frameworks, tag libraries, or JavaScript and all the labor overhead they imply. As such, here's a snippet of what a Hello World application might look like:
import thinwire.ui.*;
import thinwire.ui.event.*;
public class Hello {
public static void main( String[] args ) {
//Create and set initial position for components
final Dialog dialog = new Dialog( "Hello World, ThinWire Style!" );
dialog.setBounds( 25, 25, 215, 120 );
Label label = new Label( "Hello, what is your name?" );
label.setBounds( 5, 5, 200, 25 );
final TextField input = new TextField();
input.setBounds( 5, 35, 200, 25 );
Button button = new Button( "Ok" );
button.setBounds( 55, 65, 100, 25 );
//When button is clicked, close modal dialog and say hello
button.addActionListener( "click", new ActionListener() {
public void actionPerformed( ActionEvent ev ) {
MessageBox.confirm( "Hello " + input.getText() + "!" );
dialog.setVisible( false );
}
} );
//Add components to dialog
dialog.getChildren().add( label );
dialog.getChildren().add( input );
dialog.getChildren().add( button );
//Show dialog and wait for "OK" press
dialog.setVisible( true );
}
}
Looks almost exactly like a Swing app huh? Pretty sweet - no HTML/JavaScript/CSS/DHTML necessary.
So, given that it looks like a normal 'standalone' application, you might think to integrate Spring by just manually instantiating a ClassPathXmlApplicationContext with your spring.xml files on the claspath, and be on your way.
Unfortunately, this isn't a good idea.
You see, because this is a web application, we only really want one ApplicationContext for the entire application, which is standard operating procedure for Spring webapps. But, without delving into the ThinWire source code, you wouldn't know that there is a ThinWire Application instance per user HttpSession. Since I've already 'delved' for you, you can read on comfortable knowing that we won't instantiate a full Spring ApplicationContext (including connection pools, and Hibernate SessionFactories and everything else) per user. That would be bad.
So, how do all of the per-user ThinWire Application instances access the single Spring ApplicationContext? Well I thought it might be as easy as something like
WebApplicationContext appCtx = WebApplicationContextUtils.getWebApplicationContext( servletContext );This is after all how most other frameworks access the ApplicationContext when there isn't native Spring integration code. I thought it would be just as easy. But, unfortunately it isn't (don't worry, a good, fairly clean solution is below - keep reading).
My initial idea was to acquire the ServletContext somehow, either via a ServletFilter or ContextListener. I thought I could create a ServletFilter that wraps the ThinWire servlet, then during the doFilter( request, response ) method, I could just just get the WebApplication context and bind it to the thread via a ThreadLocal so it would be accessible to any execution code in my ThinWire Application. Then, I could have done this anywhere within my ThinWire application code:
//after receiving a gui event, say after a 'delete user' button was clicked:
Integer userId = //get user id from button event
WebApplicationContext appCtx = (WebApplicationContext)myThreadLocal.get();
UserManager userManager = appCtx.get( "userManager" );
userManager.delete( userId );
Unfortunately, as you might have expected, this won't work.
When the ThinWire servlet creates a new Application, that Application object creates an Event thread for the Application - exactly the same way Swing operates. When a request comes in, ThinWire creates an Event based on the request, and hands it off the the Application's Event queue (which is processed by this separate Event thread). So, this means the incoming HttpServletRequest thread is not the same thread that the processes the Event. So, binding the WebApplicationContext to the ThreadLocal in a servlet filter will not work, since that thread is not the one that calls the gui. Bummer 
So, my next step was to see if the ServletContext can be attached to that seperate Event thread the first time the user's Application instance is created. Nope - that won't work either, since ThinWire doesn't pass it along during creation of the event thread, and its not something I can ovverride (the ThinWire WebApplication class is final - I can't subclass it to add this behavior - I'll have to talk to the TW guys about that or at least seeing if I can contribute a revised version using the Template design pattern allowing subclass hooks for special behavior. But anyway, I digress...).
So, I can't attach the WebApplicationContext to the request thread, and I can't pass it off to the Event thread. So, the only thing I'm stuck with (again, without changing the ThinWire API) is to use a static class attribute and store the appCtx in static memory. Ugh, I hate doing that (I hate statics), but its the only option at the moment. So we'll do that.
But, where does should this static WebAppliationContext instance reside?
As I mentioned previously, one can manually create a ClassPathXmlApplicationContext instance inside your ThinWire application's main method, and assign to a static class attribute, accessible by any other of your application classes.
But, I don't like this approach. Manually creating instances is less desirable when Spring has already gone through the trouble (and done quite a nice job I might add) in setting up a Spring WebApplicationContext for me just by web.xml configuration. So, I'd much rather use this already-existing, easier-to-configure mechanism, than doing it myself.
So, the following web.xml config is how Spring does this for standard webapps:
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
log4jConfigLocation
/WEB-INF/log4j.properties
org.springframework.web.util.Log4jConfigListener
org.springframework.web.context.ContextLoaderListener
]]>
But, we need to make the WebApplicationContext instance accessible statically. So, I feel the best way to do this is to subclass Spring's ContextLoaderListener. The subclass assigns it to a static variable:
package com.domain.myapp.web.servlet;
import org.springframework.web.context.ContextLoaderListener;
import org.springframework.web.context.WebApplicationContext;
import org.springframework.web.context.support.WebApplicationContextUtils;
import javax.servlet.ServletContextEvent;
/**
* @author Les Hazlewood
*/
public class StaticContextLoaderListener extends ContextLoaderListener {
private static WebApplicationContext webAppCtx = null;
public void contextInitialized( ServletContextEvent event ) {
super.contextInitialized( event );
webAppCtx = WebApplicationContextUtils.getRequiredWebApplicationContext( event.getServletContext() );
}
public void contextDestroyed( ServletContextEvent event ) {
webAppCtx = null;
super.contextDestroyed( event );
}
public static WebApplicationContext getWebApplicationContext() {
return webAppCtx;
}
}
Then we have to change the appropriate snippet in web.xml to use this class instead of the parent:
com.domain.myapp.web.servlet.StaticContextLoaderListener
There! Now the WebApplicationContext will be accessible to any of my ThinWire Application's code whenever I need it by calling StaticContextLoaderListener.getWebApplicationContext();
But - we're not quite done - one last step to go. Its kind of ugly to call the StaticContextLoaderListener directly in your code, and, it doesn't have any other methods to be of use in your ThinWire application. So, I add one more class to wrap this call and provide other utility methods:
package com.domain.myapp.util;
import org.springframework.beans.BeansException;
import org.springframework.web.context.WebApplicationContext;
import com.domain.myapp.party.UserManager;
import com.domain.myapp.web.servlet.StaticContextLoaderListener;
/**
* This is really a ServiceLocator, using the Spring WebApplicationContext for location. Not ideal (I would rather have
* ThinWire support Dependency Injection so I don't need to use the ServiceLocator pattern), but it suffices until that (if ever) is implemented.
*
* @author Les Hazlewood
*/
public final class Spring {
//wraps the StaticContextLoaderListener call so the rest of your app code
//doesn't have to 'know' about that class:
public static WebApplicationContext getAppCtx(){
return StaticContextLoaderListener.getWebApplicationContext();
}
//returns any bean from the Spring appctx:
public static Object getBean( String name ) throws BeansException {
return getWebApplicationContext().getBean( name );
}
//more convenient typesafe call that should be used by app code directly:
public static UserManager getUserManager() {
return (UserManager)getBean( "userManager" );
}
}
Finally. Spring support is finished.
Now, if you compare the previous button event code above, it would look like this now:
//after receiving a gui event, say after a 'delete user' button was clicked:
Integer userId = //get user id from button event
UserManager userManager = Spring.getUserManager();
userManager.delete( userId );
Much cleaner! You can now use these Spring.* utility methods in any part of your ThinWire application code.
Happy coding w/ ThinWire and Spring!