• Spring.Advantages?
• Spring.Problems
• Main.Links?
• Main.Reviews

Information regarding the spring framework

1. small footprint spring-core.jar only 265k, spring-context.jar (276k), etc.
2. abstraction of dependend beans/services/data to interfaces and therefore totally replaceable implementations
3. PropertyEditor, implicit object creation
4. always use minimum interfaces for dependend objects e.g RessourceLoader instead of ApplicationContext (stubbing)

interesting stuff collected while reading the Wrox Book

• IoC
  • Mixing of autowire, constructor-arg, property elements (latter have precedence)
  • factory method of other beans for creating beans: attributes: factory-method=methodName, factory-bean=beanName

• Context instatiation (p.51)
  • multiple XML-files possible,also equally named xml files spread over the classpath

• Bean lookup
  • ctx.getBean()
  • ctx.getBeansOfType(Class)

• bean identification
  • id for xml-id conform names
  • other names via name=
  • comma separated list
  • different names for different using beans (substitution of only some of the usages possible)

• pre instatiation of singletons
  • overriden by default-lazy-init (global), lazy-init (bean)
  • ApplicationContext default
  • BeanFactory manually

• method injection (p.44)
  • when a singleton,stateless objects needs to use a non-singleton,stateful, not threadsafe object
  • abstract Method in bean
  • implemented by lookup-method element with method name= and bean= name, which is or is no singleton (depending on necessity)

• TODO inteface injection (from Manning,Spring in Action)
  • inject new interface into existing bean
  • invocation-handler, interfaces

• property values
  • (bean (inner bean)|ref (beanName)|idref|list(value)|set(value)|map(entry key=|value)|props|value|null)
  • special Collection Classes via FactoryBeans eg. ListFactoryBean
  • idref: beanName, automatic check for existence
  • ref bean= spring validation ; local= xml parser verification if in the same xml file; parent= from parent xml file (in case of name-conflicts)

• inner beans for single use beans that are unessecary outside
  • never singletons (even with flag)
  • outer bean singleton-only one inner bean, outer bean prototype then every inner prototype as well, if singleton needed via outer bean declaration/name

• manual dependency - depends-on="beanName", for non property dependencies (e.g. JdbcDriver)

• autowiring - use with care
  • globally default-autowire
  • error check unset,mandatory propertise via dependency-check=objects

• constructor argument matching
  • always use index= or type= when using constructor arguments

• Validating dependencies - dependency-check (which properties must be completely set)
  • none, simple (primitive,collections), objects (!simple), all

• callback methods
  • init-method, InitializingBean (IF) destroy-method, DisposableBean (IF)

• factory method for creating objects

• Factory Beans (FB) create/deliver beans when being accessed via getBean()
  • access of the factory bean via "&beanName"
  • examples JndiObjectFB, ProxyFB, TransactionProxyFB, RmiProxyFB (and several other remoting FBs), LocalSessionFB (Hibernate and other ORM/iBATIS), LocalStatelessSessionPropxyFB (JNDI local session beans), MethodInvokingFB, FieldRetrievingFB (delivers Method Results/Field Values as beans)

• PropertyPathFB
  • gets the value of an Property(-path) of any bean
  • different notations
  • either via targetBean=,propertyPath=
  • or using the bean id as complete property Path (e.g. id="person.address.city")

• FieldRetrievingFB
  • especially for static Fields (also other)
  • notations: property name="staticField" <value>java.lang.Long.MAX_VALUE</value>
  • or via id=java.lang.Long.MAX_VALUE
  • non static via targetObject, targetField

• MethodInvokingFB
  • use factory-method when creation of beans needed
  • call to other (also static methods) possible via
  • staticMethod, value package.Class.methodName; parameters= value or list or sth.

• Template definition (p.73)
  • define template with abstract=true property (mostly; abstract beans can't bean instatiated)
  • and use parent="templateBeanName" in concrete child configurations, save all definitions from the parent and replace/add necessary properties for the child
  • properties/constructor arg are only 'added
  • depends-on, autowire, dependency-check, singleton, lazy-init are never inherited
• BeanFactoryPostProcessor/BeanPostProcessor
  • run manually in pure BeanFactories

• PropertyPlaceHolderConfigurer (p.77)
  • replace ${propname} properties in config file with values from an *.properties file
• PropertyOverrideConfigurer (p.78)
  • implicitely replace properties from the *.properties file(s)
    e.g. beanName.proprertyName=propertyValue
  • in the beans/proeprties listed in the properties file - use with caution and document

• PropertyEditor p.102
  • maps String values to Java Objects
  • via PropertyEditorSupport (configure by CustomEditorConfigurer)
  • if placed in the same package as the type with the same name and Editor appended, it is automatically installed by the JavaBeans PropertyEditor mechanisms
  • default propertyEditors: ByteArray, Class, CustomBoolean, CustomNumber(String to any Number), File, InputStream, Locale, Resource, ResoureArray(wildcards), StringArray, URL, CustomDate(must register manually), StringTrimmed(also emtpy to null), CustomCollectionEditor(new)

• AutoProxying
  • BeanNameAutoProxyCreator

• Resource
  • transparent lookup in FileSystem,ClassPath,WebContext depending on ApplicationContext-Type or prefix
  • set Resources directly via text value and PropertyEditor setMyResource(Resourse myRes)

• MessageSource
  • automatic Hierarchy via the ApplicationContext hierarchy
  • set directly in bean without MessageSourceAware
  • MessageSourceAccessor for simpler locale handling

• Timer, Scheduling facilities
  • TimerTask.run()
  • schedule with ScheduledTimerTask, property for period (ms)
  • TimerFactoryBean configured with any number of scheduledTimerTasks

• Component Handling p.97
  • not satisfying
  • supply xml-descriptor with component jars, use namespaces for bean-ids (eg. component- or : ) I'd prefer package names
  • use bean aliasing for supplying the same bean to different components (e.g. DataSource)

• Singletons for accessing the Container (todo)
  • SingletonBeanFactoryLocator
  • in ejb context

• Unit Testing
  • use direct test code injections via setter or constructor
  • from spring-mock.jar
  • AbstractDependency
  • cactus for in Container Tests (ant like remote tests)
  • webtest.canoo.com

• Mock Objects for Testing
  • either static versions
  • or use, EasyMock p.105 or jMock

• Bean aliasing
  • <alias name="fromName" alias="toName"/>