Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the ability to turn off automatic derivation of Aliases for custom parsers. [SPR-12643] #17244

spring-issuemaster opened this issue Jan 19, 2015 · 1 comment


None yet
2 participants
Copy link

commented Jan 19, 2015

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:

/** {@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



Affects: 4.1.3

1 votes, 4 watchers


This comment has been minimized.

Copy link
Collaborator Author

commented Jan 20, 2015

Juergen Hoeller commented

Good point! Addressed through the introduction of a "shouldParseNameAsAliases()" template method.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.