Legacy config parsers and boolean attribute/predicates

[Brent Putman]

On 10/17/15 11:14 AM, Rod Widdowson wrote:
>> .  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.

Thanks for reminding me of this (again).

One of these days I'm going to successfully internalize property
replacement vis-a-vis the parsers and the related usage of FactoryBeans
and BeanDefinitionBuilders inside of them.  But apparently not yet...

>
>> 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.

Thanks for the hints.  That's what I did and it works perfectly.


>
>> 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?

Probably, you're right.


>  I'm also not sure how it would be made to work. 

I wasn't thinking about property replacement etc.  Without *that*
requirement my thought was it's pretty simple - look at the attribute
value and if it's true/false/1/0, treat it like a boolean, otherwise
treat it like a bean ref.  But totally not worth it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20151021/16c6de04/attachment.html>