-
Notifications
You must be signed in to change notification settings - Fork 37.7k
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
Spring XML bean definition parser interprets <constructor-arg/> tags that are not in the beans namespace [SPR-7218] #11877
Comments
Juergen Hoeller commented Ben, where is that parseBeanDefinitionElement call coming from - would be good to see the complete stacktrace there. We're only really calling that for the default namespace... Or is your namespace handler performing that call somewhere, in order to parse common bean definition attributes maybe? Juergen |
nebhale commented Sorry about that. Just grab the subexception that seemed most pertinent. Here's all that I get:
I'm using the NamespaceHandlerSupport class to register a |
Juergen Hoeller commented Hmm, this is the regular call stack for a <bean> element in the default namespace... Could you debug why DefaultBeanDefinitionDocumentReader's parseBeanDefinitions thinks that your element lives in the default namespace? It basically parses your top-level element like it was a regular <bean> element - and <constructor-arg> just happens to be a well-known subelement there. A possible reason could be that the Element's namespaceURI is empty - maybe due to XML parser settings? Juergen |
nebhale commented That might be the issue then. Basically I have something that looks like this: <bean class="org.springframework.slices.samples.slice2.Bean">
<slices:constructor-arg type="org.springframework.slices.samples.slice1.EchoService"/>
</bean> Is it possible that the |
Juergen Hoeller commented Yes, that's probably it. We're not checking for the namespace there at that level. So we'll simply have to restrict parsing to sub-elements which actually live in the default namespace themselves. Your slices:constructor-arg would then be picked up by a BeanDefinitionDecorator, I suppose (like when having a different name). Juergen |
nebhale commented Sounds good to me :) I'm not surprised this has never come up as there are very few use-cases to provide alternate declarations of the common tags. |
Juergen Hoeller commented Fixed through additional namespace checks at the element parsing level. Will be available in tonight's 3.0.3 snapshot. Would be great if you could give it a try tomorrow... Juergen |
nebhale opened SPR-7218 and commented
I've got a namespace which defines a
slices:constructor-arg
element (to be used in place of thebeans:constructor-arg
element). When running up an ApplicationContext I get the following error:Simply changing the name of my tag to something other than
constructor-arg
resolves the issue. I've not tried with some of the other well known names (property
comes to mind) but there might be issues there as well.Affects: 3.0.2
Issue Links:
Referenced from: commits 2676771, a6d9c90
The text was updated successfully, but these errors were encountered: