Chapter 3 - advanced Spring

Ok, starting to read chapter 3 of Spring Recipes.

The first section is a basic description of using injection for properties and constructors - nothing advanced about that!

4-2 introduces the "factory-method" keyword in a bean declaration. It tells Spring that class is being created by a static method, and the class name given is the factory class name, not the class produced.

4-3 adds the "factory-bean" configuration keyword. It invokes what the author refers to as an "instance factory method". The basic concept is that the instances of beans are created and stored in a map, which itself is stored in a ProductCreator class. The ProductCreator class is created with xml that uses "property name" to represent the map, "map" to describe the map, "entry key" to describe the key to the map, and the "bean class=..." to describe the beans that go into map.

Then it instantiates the beans by specifying the "factory-bean" in the "bean id=... xml statement, along with the "factory-method" to identify the method used to get the bean.

Whew, that was long-winded.

4-4. Spring has this concept of a "Spring Factory Bean". Keep in mind that we are dealing with a superclass Product and subclass of Battery and Disc. The superlcass's "setPrice" can be called on whichever subclass of Product is set for the DiscountFactoryBean. So, when you create your subclass instances, you will be first setting the discount value, and the createInstance method of the AbstractFactoryBean implementation will do whatever it needs with the discount (setPrice in this case) when Spring calls the "createInstance", which you set up in the AbstractFactoryBean implementation (i.e. the DiscountFactoryBean"). Note that you also implement the product.getType method, which is a mere formality.

4-5. This talks about ways to configure beans that are statically defined in a class. You use the FieldRetrievingFactoryBean in the "bean id=..." statement, and then you give a "property name="static-fied", and then a value of the class anem and the static field name in a "value" property.

Another way is to skip the property declaration, and in the bean id give the static fields class and name, while specifying the class as FieldRetrievingFactoryBean.

Another way is to ad the "util" schema declaration to the root element, then use the "util:constatnt" tag, where you give the id as, e.g., aaa, and then specify a "static-field" as the static field defining the instance.

God, this is too dull for words. Ok, let's shorten up the explanations a bit.

4-6 is about the "PropertyPathFactoryBean". If an inner bean is a property of another class, it lets you pull that property and declare it as a bean in its own right. You can also combine the bean name and its property as the bean id, giving the class as the PropertyPathFactoryBean.

Naturally, in 2.x they've made a tag to cover this, if you add the "util" xsd.

You just have to say "util:property-path id="bestSeller" path="productRanking.bestSeller"

4-7 is about bean scopes. The trick here is to understand that the default is singleton when you get a bean. In other words, if you do a "context.getBean("shoppingCart"), it will always return the same instance. This means that the "getBean" is not doing a "new". To make the getBean do a "new", you have to give it a "scope="prototype" in the bean declaration".

My God. This stuff is deadly. One more...

Ok. This is good to know. Spring lifecycle management has an "afterPropertiesSet" and "destroy" method that are implementations of the "IntializingBean" and "DisposableBean" properties, respectively. So, if you need to open a file and close a file, do them in these methods. The book points out that it's helpful in particular in the case of "afterPropertiesSet", due to the fact that the properties that are set are the file an path name.

However, a better approach is to use the "init-method" and "destroy-method" in the bean id= declaration. That way, you don't have to implement the interfaces, just to call the "open-file" and "close-file" methods.

The third way (there's always a third way) is to use @PostConstruct and @PreDestroy" annotations. Just make sure to include "bean class="CommonAnnotationBeanPostProcessor" in your beans.xml.

Or, of course you can add the "context" shcema definition, and then just use the "context:annotation-config" tag in your bean somewhere. Actually, the second seems better.

Oh my good sweet Lord. There is more. There is always more. Just think - if I learn this stuff, and learn it fast, I can get a new job. A better job. I'll have more options. Spring is the BIG technology. Learn it!

4-9 This is about making beans aware of the container. For example, take the BeanNameAware interface. Say you name your bean "cashier1" (as the bean id).

So, you implement "setBeanName" as this.name = beanName in that method. So, now your bean has a name property which it pulled from the configuration.

As a piece of trivia, this is called after the bean properties are set, but before the initialization callbacks.

Dear God in Heaven - this is excruciating. C'mon you can do it. Think about the job. Think about the job.

4-10. The ultra-exciting topic of Create Bean Post Processors. My God.

Stop.