Resources.

[Tom Zeller]

>> ... duplicate the filtering subsystem ...
>> or whether we can use the Spring's property placeholder. It seems that to do
>> that we would need to revert to using factory beans again -
>> http://stackoverflow.com/questions/12936080/using-a-properties-file-with-a-c
>> ustom-bean-parser. But do we feel the need for this?  Can we not just state
>> that if we want to drive configuration from a properties file we just write
>> the native spring XML to do it?
>
> I would feel comfortable making the decision to wire back in the
> factory beans in v3 to support post-processing, especially as we are
> (a) avoiding new extensible XML authoring and we are (b) using Spring
> more, meaning Web Flow, Resources, native XML config for the
> LDAPDataConnector, etc.
>
> If we so choose, the work should be straightforward, like house painting.
>
> Open to discussion ...

Oh. Actually, maybe we can provide a default factory bean, I think I
had worked one up with dependency injection via constructor, maybe
setter would be better, but I did something like :

AbstractFactoryBean<T> extends AbstractFactoryBean

 private T t;

 AbstractFactoryBean(T someT) {
  t = someT;

T getObject() {
 return t;
}

SomeFactoryBean<SomeFactory> extends AbstractFactoryBean {

 public SomeFactoryBean(SomeFactory someFactory) {
  super(someFactory);
 }

but those generics are probably wrong.