Add the ability to turn off automatic derivation of Aliases for custom parsers. [SPR-12643] #17244
Labels
in: core
Issues in core modules (aop, beans, core, context, expression)
type: enhancement
A general enhancement
Milestone
Rod Widdowson opened SPR-12643 and commented
We (The Shibboleth team), just rolled out a new version based on Spring 4.1.3 and a customer has tripped over an unfortunate side effect of the use of the attribute name=”whatever” as an alias for the bean.
We make extensive use of custom schema parsing and in one such schema we have a specific use for an attribute “name”. It is in the nature of this attribute that the value (which is not used as a bean, but as an on-the-wire string) will have the same value as a different spring bean id.
The net result is that after our custom parser has done its stuff, AbstractBeanDefinitionParser#parse comes along an unconditionally pulls the content of the attribute called “name” and makes an alias.
This alias then tramples on the different bean definition with that id.
Things then rapidly deteriorate at this stage.
We have “fixed” this by overriding the method “registerBeanDefinition” in our parser:
But this is ugly and makes more use of internal knowledge than we’d like.
Our suggestion is that you introduce another protected boolean method like “shouldGenerateId()” called (shall we say) ”shouldParseAliasesFromName()” with a default value of true. You then consult this prior to creating the alias.
I can provide example code if you want, or even a proposed patch. Or you might like to see our workaround in situ at
http://svn.shibboleth.net/view/java-identity-provider/trunk/idp-attribute-resolver-spring/src/main/java/net/shibboleth/idp/attribute/resolver/spring/enc/BaseAttributeEncoderParser.java?revision=7253&view=markup
Thanks
Rod
Affects: 4.1.3
1 votes, 4 watchers
The text was updated successfully, but these errors were encountered: