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:
/** {@inheritDoc} * We do <em>not</em> want Spring to add aliases derived from {@literal #NAME_ATTRIBUTE_NAME} so strip them out
* from the registry. */
@Override protected void registerBeanDefinition(BeanDefinitionHolder definition, BeanDefinitionRegistry registry) {
// Register bean definition under primary name. Do *not* register the aliases.
String beanName = definition.getBeanName();
registry.registerBeanDefinition(beanName, definition.getBeanDefinition());
}
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
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