Java tips

Spring 2.5 - Too much auto-wired?

2007-11-29T16:17:00.000-08:00

Concept to auto-wire relationships among spring enabled beans has always been there. The idea with auto-wiring is to get away from the tedious task of specifying and more importantly maintaining explicit wiring. Originally it was supported to be done by name, by type, by constructors or auto-detect and then you had the option to auto-wire all or specific beans within a context. But now with Spring 2.5 the auto wiring concept has taken a whole new meaning and so is the debate if we really want to do auto-wiring. Spring 2.5 has a new @Autowire annotation. @Autowire annotation let us do much fine grained auto-wiring then was possible before and also it make us much more explicit then was possible in pre Spring 2.5 times Lets consider few examples #1

@Autowired
public void init(AccountDao accountDao, CustomerDao customerDao) {
   this.accountDao = accountDao;
   this.customerDao = customerDao;
}

Do not need to have setters with one parameter to inject dependencies, any method with any name and any number of parameters will do. Can be applied to fields and constructors as well and obviously to the favorite setters :) #2

@Autowired
private BaseDao[] daos;

@Autowired
private Set daos;

Create an array or collection with all the possible beans available in the context.. #3

@Autowired(required=false)
private AccountDao accountDao = new AccountDao();

Find it do it, if not leave it. Moving on we can even fine control this by using another annotation @Qualifier. Again lets see some more examples #4

@Autowired
@Qualifier("bankService")
private BankService bkService;

We are doing by-name auto-wiring by providing a bean name within the annotation. This might help by letting you declare the name of the property different from the name of the bean. #5 – Example of custom qualifier annotations to take care of the case when we have more then one implementation which we want to auto-wire Define an annotation like this

@Target({ElementType.FIELD, ElementType.PARAMETER})
@Retention(RetentionPolicy.RUNTIME)
@Qualifier
public @interface Category {
   String value();
}

Custom qualifier on autowired fields can be applied like this

public class BookList {
   @Autowired
   @Category("Technical")
   private Book technicalBook;

   @Autowired
   @Category("Management")
   private Book managementBook;

}

and then do the bean definitions like this

<bean name="book" class="example.Book">
    <qualifier type="Category" value="Technical"/>
    <!-- This implementation specific properties -->
</bean>
<bean name="book" class="example.Book">
    <qualifier type="Category" value="Management"/>
    <!-- This implementation specific properties -->
</bean>

And if this is not enough we can always create a custom auto-wire configurer or may be use the new @Resource annotation for further auto-wiring stuff. That is that for auto-wiring but Spring 2.5 introduces a concept of auto-detection of spring components on the classpath where we do not have to even define the beans (with the name and bean class) in the context. Spring does a component scanning on the classpath (which can be configured using filters) by detecting classes which are stereotyped and then registering them as spring enabled beans. Yes it provides a lot of flexibility and a much greater control as can be seen from all of the above examples but still I feel it should be done with a lot of caution and I-am-going-to-be-consistent attitude.

Ten Common Misconceptions about Grails

2007-11-23T06:29:00.001-08:00

As is usually the case with anything "new" there’s a lot of FUD and confusion out there with people who have not used Grails yet, that may be stopping them using it. Here’s a quick list of some of the more common falsehoods being bandied about:

"Grails is just a clone of Rails". Ruby On Rails introduced and unified some great ideas. Grails applies some of them to the Groovy/Java world but adds many features and concepts that don’texist in Ruby, all in a way that makes sense to Groovy/Java programmers.

"Grails is not mature enough for me". The increasing number of live commercial sites is the best answer to that. Its also built on Hibernate, Spring and SiteMesh which are well-established technologies, not to mention the Java JDK which is as old as the hills. Groovy is over three years old.

"Grails uses an interpreted language (Groovy)". Groovy compiles to Java VM bytecode at runtime. It is never, ever, ever interpreted. Period. Never. Did I say never ever? Really.

"Grails needs its own runtime environment". Nope, you produce good old WAR files with "grails war" and deploy on your favourite app container. During development Grails uses the bundled Jetty just so you have zero configuration and dynamic reloading without container restarts.

"My manager won’t let me use Grails because it isn’t Java". Smack him/her upside the head then!** Grails code is approximately 85% Java. It runs on the Java VM. It runs in your existing servlet container. Groovy is the greatest complement to Java, and many times more productive. You can also write POJOs for persistence to databases in Java and include Java src and any JARs you like in a Grails application, including EJBs, Spring beans etc. Any new tech can be a hard sell in a cold grey institution, but there’s rarely a more convincing argument than "Hey Jim, I knocked up our new application prototype in 1hr in my lunch break with Grails - here’s the URL". [** comedy violence kids, not the real kind]

"Grails is only for CRUD applications". Many demos focus on CRUD scaffolding, but that is purely because of the instant gratification factor. Grails is an all purpose web framework.

"Scaffolding needs to be regenerated after every change". Scaffolding is what we call the automatically generated boilerplate controller and view code for CRUD operations. Explicit regeneration is never required unless you are not using dynamic scaffolding. "def scaffold = Classname" is all you need in a controller and Grails will magic everything else and handle reloads during development. You can then, if you want, generate the controller and view code prior to release for full customisation.

"Grails is like other frameworks, ultimately limiting". All Grails applications have a Spring bean context to which you can add absolutely any Java beans you like and access them from your application. Grails also has a sophisticated plugin architecture, and eminently flexible custom taglibs that are a refreshing change from JSP taglib.

"I can’t find Grails programmers". Any Java developer is easily a Grails developer. Plus there are far fewer lines of code in a Grails application than a standard Java web application, so getting up to speed will be much quicker.

"Grails will make you popular with women". Sorry quite the opposite, you will be enjoying coding so much you won’t be chasing any women for a while. We should put this as a warning in the README actually, along with a disclaimer about any potential divorce that might result from hours spent playing with your Grails webapps.

By Marc

Controlling Classloading with Spring

2007-11-20T13:08:00.000-08:00

The Spring Framework provides tons of functionality for someone wanting to use dependency injection; so much so that it can be difficult to know everything you can do.

Many times when dealing with a framework or a web application, it becomes important to track down JAR files and class files at runtime, and load them, often times in their own ClassLoader object.

Just to remind everyone out there, classes loaded in one ClassLoader are not visible to a parent or sibling ClassLoader (unless you are using some nightmare ClassLoader object that breaks the hierarchical semantics of core Java classloading).

ClassLoaderA
| (ClassA, ClassB, ClassC)
|
|__ ClassLoaderB (Child of A)
|   (ClassD, ClassE)
|
|__ ClassLoaderC (Child of A)
(ClassF, ClassG)

Using this diagram as an example, ClassLoaderB can see ClassA, ClassB, ClassC, ClassD, and ClassE, but it cannot see ClassF or ClassG. Likewise, ClassLoaderC cannot see the classes loaded by ClassLoaderB. And finally, ClassLoaderA can only see it's own classes.

Thankfully, objects loaded by child/sibling classloaders can be dealt with in classes loaded by parent/peer classloaders (this can be seen when you put one of your objects in to an ArrayList object - the ArrayList may not be able to reference your class, but it can still deal with the objects inside of that class.

Considering the above, what if we want to use a Spring XMLBeanFactory object (created by ClassLoaderA) to load a bean definition in an XML file that is referring to ClassD which is inside ClassLoaderB?

Thankfully, it is a fairly simple process; it simply involves understanding the two pieces at work. We have:

A Bean Definition Reader - This is the object that reads the bean definition from the source (redundant, aren't I?); in other words, in this case this is the XML parser and magical finder of Class objects when you type ....
A Bean Factory - This is the implementation of the factory that handles the construction of beans after they have been defined by the reader. This is the stage in the process where AOP, autowiring, property setting, singletons, prototypes, etc is all plugged in.

So now, being infinitely more educated on the Spring bean factories, it is just a short hop to plugging in the correct class loader ClassLoaderB for the task at hand.

The BeanDefinitionReader is where classes are found when Spring is parsing/interpreting a bean definition source (such as a bean XML file). There is a method on the interface - BeanDefinitionReader.getBeanClassLoader() that provides the correct class loader to the BeanFactory (this defaults to Thread.currentThread().getContextClassLoader()). There is also a method on the abstract base implementation - AbstractBeanDefinitionReader.setBeanClassLoader(ClassLoader) so we can set our class loader to the correct implementation.

'But wait R.J.!', you say - 'There is no BeanDefinitionReader that I can see on the XmlBeanFactory class - you're a liar! I'm never reading Coffee-Bytes again!'. Don't pull away from me yet! While it is true that the XmlBeanFactory class doesn't provide visibility to the bean definition reader, that doesn't mean it's not there! In reality, the XmlBeanFactory is just a convenience implementation of two seperate objects:

XmlBeanFactory factory = new XmlBeanFactory([xml resource here!]);
// == to
XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader();
DefaultListableBeanFactory factory = new DefaultListableBeanFactory(reader);
reader.loadBeanDefinitions([xml resource here!]);

Do I think it is frustrating that you can't get to the bean definition reader without forgoing the XmlBeanFactory class for it's super class? Absolutely! Do I have commit rights to Spring? Unfortunately for them, no (hint, hint). So, that's that... oh, you still don't feel that sweet cut/paste solution beckoning to you? Am I leaving you patient readers hanging without a clean solution to your problems? Ok, ok...

XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader();
reader.setBeanClassLoader([Class LoaderB here!]);
DefaultListableBeanFactory factory = new DefaultListableBeanFactory(reader);
reader.loadBeanDefinitions([xml resource here!]);