Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

In V2 the preferred paradigm was to write a Factory Bean for every object for which you had a parser.  In V3, although it does not case any problems to have a FactoryBean, it is not always usually required.

However it It is important to understand when you must implement a Factory Bean.

A Factory Bean is required if the plugin you have implemented takes a parameter (via a bean setter or a constructor) which is not a String or an object Object which Spring can convert into from a String.  The IdP String infrastructure has a reasonably wide set of functions to convert from Strings to other types:

...

Code Block
languagexml
<plugin:Parent numerator="22" denominator="7" name="pi"/>

You might intially write parsing code like this

Code Block
languagejava
titleBroken parsing
	final String id = StringSupport.trimOrNull(child.getAttributeNS(null, "name"));
	builder.addPropertyValue("id", id);
	final String num = StringSupport.trimOrNull(child.getAttributeNS(null, "numerator"));
	final String denom = StringSupport.trimOrNull(child.getAttributeNS(null, "denominator"));
	final Rational rational = new Rational();
	rational.setDenominator(Integer.decode(denom));
	rational.setNumerator(Integer.decode(num));
	builder.addPropertyValue("rational", rational);

...

A special case of this is the org.springframework.beans.factory.support.ManagedList.  If a ManagedList is passed to addPropertyValue or addConstructorValue, then Spring treats this as a special list and applies any conversions to the contents prior to bean creation.  So, for instance if the element of a ManagedList is "%{idp.property}" then this is replaced prior to any bean it is injected into being instantiated, whereas if this was an ArrayList it would not be replaced.

...