stopWatch.stop();
System.out.println("1000000 invocations took: "
+ stopWatch.getTotalTimeMillis() + " ms");
}
}
You should be very familiar with this code by now, so we won't go into any detail on it. On our
machine, running this example yields the following output:
<h2>Hello World!</h2>
1000000 invocations took: 363 ms
<h1>Hello World!</h1>
1000000 invocations took: 107 ms
As expected, the output from the replacementTarget bean reflects the overridden implementation
that the MethodReplacer provides. Interestingly, though, the dynamically replaced method is more than
three times slower than the statically defined method. Removing the check for a valid method in the
MethodReplacer made a negligible difference across a number of executions, so we can conclude that
most of the overhead is in the CGLIB subclass.
When to Use Method Replacement
Method replacement can prove quite useful in a variety of circumstances, especially when you want to
override only a particular method for a single bean rather than all beans of the same type. That said, we
still prefer using standard Java mechanisms for overriding methods rather than depending on runtime
bytecode enhancement.
If you are going to use method replacement as part of your application, we recommend you use one
MethodReplacer per method or group of overloaded methods. Avoid the temptation to use a single
MethodReplacer for lots of unrelated methods; this results in lots of unnecessary String comparisons
while your code works out which method it should reimplement. We have found that performing simple
checks to ensure that the MethodReplacer is working with the correct method is useful and doesn't add
too much overhead to your code. If you are really concerned about performance, you can simply add a
boolean property to your MethodReplacer, which allows you to turn the check on and off using
Dependency Injection.
Understanding Bean Naming
Spring supports quite a complex bean naming structure that allows you the flexibility to handle many
different situations. Every bean must have at least one name that is unique within the containing
ApplicationContext. Spring follows a simple resolution process to determine what name is used for the
bean. If you give the <bean> tag an id attribute, then the value of that attribute is used as the name. If no
id attribute is specified, Spring looks for a name attribute, and if one is defined, it uses the first name
defined in the name attribute. (We say the first name because it is possible to define multiple names within
the name attribute; this is covered in more detail shortly.) If neither the id nor the name attribute is
specified, Spring uses the bean's class name as the name, provided, of course, that no other bean is using
the same class name. In case multiple beans without an ID or the name defined are using the same class
name, Spring will throw an exception (of type org.springframework.beans.factory.NoSuchBean
DefinitionException) on injection during ApplicationContext initialization. Listing 4-67 shows a sample
configuration that uses all three naming schemes.
Search WWH :
