Spring's ObjectFactory

More fun with Spring scopes "This time I would like to show another interesting application for the custom bean scopes. In this case conversation is bound to the page in web application (or even to each unique set of request parameters for that page). Practical examples include per-page caching of the static data (i.e. for Ajax use), allow page visitors to interact or edit page content together and many others..."

The Springframework reference has another example of using the ObjectFactory, "Knowing who you are". As noted, it doesn't move away from requiring Spring but it is slightly better than being BeanFactoryAware. The limiting factor on this is that if you need to create two types of objects you need two object factories. A generic object factory could do the trick and generics could be used to remove the casting too.

A recent InfoQ article, "Spring 2.0: What's New and Why it Matters", also has a section about the new bean scopes.

A Third Way to do Transaction Management in Spring

Generally, I've oscillated between two different ways of doing transactions in Spring, the first is with declaratively using AOP and the second is programmatically throw the use of TransactionTemplate or to be really hardcore PlatformTransactionManager. I say hardcore because it's a bit more work to ensure that everything is commited or rolledback correctly.

I recently arrived at another way due to the requirements of testing the objects via interaction based testing. The AOP method makes it hard to Mock out calls as it wraps everything in a proxy and the programmatic approach seems impossible to test purely interactively (basically requiring a real TransactionTemplate). Especially as some things are classes and interfaces.

This idea combines the simple ideas of interfaces, dependency injection and either TransactionCallbackWithoutResult or TransactionCallback.

Create an interface, say "DoStuff" that has the required method to be in a transaction say, "doStuff(String stuff)". There are two implementations of this interface "DoStuffImpl" and "DoStuffInTransaction". The "DoStuffInTransaction" gets injected the "DoStuffImpl" and the "TransactionTemplate". It also implements "TransactionCallback". When it's "doStuff" method is called it sets the parameters to fields and then calls "transactionTemplate.execute(this)" and the "doInTransaction" methd calls the "DoStuffImpl.doStuff()" method.

By wiring up the "DoStuffImpl" inside "DoStuffInTransaction" your other classes can only access the transactional version. It makes interaction testing straightforward and doesn't require explicitly calling things like commit or rollback.

Getting JRDF back to 500K

JRDF does not required the use Spring in production code for anything but the user interface. You can remove Spring (about 2.5MB of the JRDF SPARQL GUI) and still be able to create a graph using:

LongIndex[] longIndexes = {new LongIndexMem(), new LongIndexMem(), new LongIndexMem()};
GraphFactory factory = new GraphFactoryImpl(longIndexes, new NodePoolMemImpl());
factory.getGraph();

In 0.4.1 an RDF parser is easier to create than before, all that's requires is:

Parser parser = new GraphRdfXmlParser(graph);

JRDF 0.4.1 will still be a stand-alone jar file that can be used outside of Spring.

Spring Best Practice

Leverage Application Framework Integration with Spring "Inversion of Control with Dependency Injection and support for Declarative Transaction are Spring framework features that can greatly reduce the complexity of integrating different application layers as well as fosters better OO design and greatly improves testability."

Good Design and Web Spreadsheets

I've been using Spring Rich Client recently and it made me think of what makes a good design pattern as I go and implement the MVC pattern.

So with object-oriented programming I have to say that the most benefit I've seen is the combination of data and behaviour which enables large parallel development. As Alan Kay has said on his history of Smalltalk, "..."doing OOP right" would be to handle the mechanics of invocations between modules without having to worry about the details of the modules themselves." This is what the naked objects guys call behavioural completeness. They quote Riel by saying: "'Keep related data and behaviour in one place.','Distribute system intelligence horizontally as uniformly as possible, that is, the top-level classes in a design should share the work uniformly.', 'Do not create god classes/objects in your system. Be very suspicious of a class whose name contains Driver, Manager, System or Subsystem.'"

As they also mention, the MVC pattern is frequently misunderstood and misused as the controllers "...take on the role of task-scripts, incorporating not only the optimized sequence of activities, but business rules also - thereby usurping what ought to be responsibilities of the core business objects." This is usually extended to MVCP (or Model-View-Controller-Peristence) where persistence is not hidden from the other layers.

So by taking this more procedural or subject-oriented view, clothing it in OOP and design patterns, it leads to an architecture that is brittle when subjected to change. This approach has been proven to be less able to adapt to changing business requirements than one that is behaviourally complete.

This also ties into the semantic web for object-oriented software developers where it says, "The key power of OWL is that classes can be defined by combining multiple restrictions and other classes. For that purpose, OWL provides logical operands to build intersections (and), unions (or) and complements (not) of other classes. For example, you could define "the class of all customers from France who have issued at least 3 purchase orders or at least one order consisting only of books, except those customers who have ordered a DVD". This is also an example of behaviour and data moving around together and being combined and types inferred - I don't see it as a contradiction between the two as long as you consider a dynamic typing system like Ruby or Java with AOP, reflection, proxies and annotations. I also see it as the killer application of things like Google's spreadsheet - in fact their spreadsheet is an almost ideal expression of this shared, global object that takes messages and performs operations.

As an aside, I went searching for where I first read about the "Design Patterns" book and it was from a review by Tal Cohen who said: "The concept of design patterns was first discussed by Christopher Alexander, an architect, back in 1977. If someone from the software industry would have considered Alexander's' words back then, perhaps the first book about design patterns in software would have dealt with patterns in FORTRAN programs. As it happens, software design patterns were first discussed in this era, when most software design is object-oriented in nature." And recently, although I don't have access to read it, someone has applied design patterns to Fortran 90/95 (might be as interesting as Object Oriented Javascript).

Extra Spring Things

Spring Modules (SM) 0.4 has been released Validation Module (based on Commons Validator), JavaSpaces and jBPM. Joining the others: cache providers, hive mind, Java Content Repository, rules (Drools, Jess, and JRules), Lucene and OSWorkflow.

The roadmap includes: Spring 2.0 support, JMX, and others.

More Spring Things

"Design enterprise applications with the EJB 3.0 Java Persistence API" lists injecting collaborators of a service using annotations such as "@EJB(beanName = "AccountDao")" to "AccountDao accountDao;".

This compares with Spring 2.0 examples that use the Spring configuration file to inject the collaborators: "JavaEE 5, Spring 2 and AspectJ 5: dependecy injection magics". Some more information, "7.7.1. Using AspectJ to dependency inject domain objects with Spring".

The other useful article is, "Don't repeat the DAO!" which allows the creation of type safe and generic DAOs. This uses dependency injection to put the class type to return and then uses Spring's AOP to add extra behaviour (like finder methods).

Another Spring 2.0 Update

What's new in Spring 2.0? " Previous versions of Spring had IoC container level support for exactly two distinct bean scopes (singleton and prototype). Spring 2.0 improves on this by not only providing a number of additional scopes depending on the environment in which Spring is being deployed (for example, request and session scoped beans in a web environment), but also by providing 'hooks' (for want of a better word) so that Spring users can integrate their own scopes with (hopefully) a minimum of effort.

It should be noted that although the underlying (and internal) implementation for singleton- and prototype-scoped beans has been changed, said change is totally transparent to the end user... no existing configuration needs to change, and no existing configuration will break."

No more Spring Session Components Workarounds. Although, custom bean scopes shouldn't be worked on until RC1.

Ben Hale's Atlanta DevCon 2006 via Atlanta DevCon 2006.

Sharing Instances in Spring

So I had a fairly basic problem that I probably have solved before but wasn't able to remember and took some time to work out.

I had three objects A, B and C. Both B and C need to share the same instance of A. But I want to create multiple Bs and Cs – so they are not singletons. I also did not want other Bs and Cs to share the one instance of A so making A a singleton was also out of the question.

There’s several ways I came up with but none of which I was particularly happy with:
1/ Flatten out the dependencies – make C depend on B which depends on A for instance.
2/ Make A a singleton and create bunches Bs and Cs by using multiple BeanFactories.
3/ I could throw away dependency injection and let the objects using B and C construct/set-up B and C using A.

The solution that I finally settled on is creating a BCFactory (interface) that requires A, constructs B and C (in the implementation) and has getB() and getC() methods.

Link Parking

• Going through the Spring Blogs and another posting: Re: Spring, just another hype? "Spring has had support for prototypes and other instantiation and scoping strategies since the early beginning. There are some limitations...For the ‘Singleton A that needs Prototype B’ problem, Spring provides several options such as lookup-methods, target sources and manual lookups."


• JTA Does Not Equal Automatic Support of Two-Phase Commit! "Now it looks like JOTM is getting (it’s in CVS, and part of a new Jonas reelase) XA recovery, but the release version doesn’t. I really welcome a version of JOTM which can do proper XA recovery. It’ll be great to have that option, but until that’s actually available there’s not really much of a reason you’d ever want to use JOTM in a new Spring app deployed in TomCat."


• Behaviour-Driven Development and JBehave.


• Radio National on the top down (American) vs bottom up (British) army (MP3) and Changing the Army for Counterinsurgency Operations (PDF).


• Pellet 1.3 and a list of SPARQL implementations.

Spring Aspects - A Transactional Thing

I've recently been looking at transactions in Spring 2.0 - it certainly has more things to make your code sing.

The Spring 2.0 Transaction document has some useful information on using a TransactionTemplate to wrap transactional operations. Of course, the best way is Spring AOP for declarative transaction management and using Java 5.0's annotations.

There's a previous discussion of applying transactions using Spring 1.x using Hibernate in, Wire Hibernate Transactions in Spring.

Javapolis Spring Update and Maven 2.0 (see also, this Maven 2.0 article) most of talks are well worth a listen.

Articles on using the new AOP features in Spring 2.0: Typed Advice in Spring 2.0 (M2) (about finding methods in Spring AOP) and POJO Aspects in Spring 2.0: A Simple Example.

An article on JPA (Java Persistance API), Using the Java Persistence API with Spring 2.0.