Legacy config parsers and boolean attribute/predicates

[Rod Widdowson]

> .  Is this horribly wrong?  

You are not allowed to interpret values in the parser if you want to support property replacement, so that’s going to be problematic.

> Is there a better simpler way?

Slightly more typing but IMO simpler code is to build a FactoryBean.  Give it a boolean setter "allowDelegation" and a Predicate setter "allowDelegationPredicate".  The buildObject logic could have the "mustn't set both" logic.  Then the parser 'just' has to strip the contents of the attributes and stuff them in to the Builder, Spring does the rest.

> Rather than add the new 'allowDelegationPredicateRef' attribute to the schema, would it 
> be more appropriate to overload 'allowDelegation' to handle both (String) boolean 
> value and bean ref?

It strikes me that this might be difficult for a deployer to understand? I'm also not sure how it would be made to work.  You might be able to just send the attribute value into the Builder as a reference and rely on the converter to do the work of change "true" to the correct predicate, but I think that you'd end up with different levels of indirection.  So you might want to make the FactoryBean ApplicationContextAware, make the setter take a string and do all the work in buildObject, but in that case you'd probably end up with dependency issues (since you have not told spring that you rely on the bean reference).

Given that this is legacy syntax, I'd be inclined to just add the "allowDelegationPredictateRef" attribute and be done with it.

> Have we done anything similar as precedent?
Nothing that spring to mind.

HTH
/R