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

Allow nested <beans> elements to be declared anywhere [SPR-8017] #12672

Closed
spring-projects-issues opened this issue Mar 2, 2011 · 9 comments
Closed
Assignees
Labels
in: core status: declined type: enhancement

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Mar 2, 2011

Mark Fisher opened SPR-8017 and commented

This appears to be a schema issue since the 'beans' element is enabled within a sequence where it would always be the last type.


Affects: 3.1 M1

Issue Links:

  • #14525 XML configuration: 'beans' element should be allowed between 'bean' elemebts ("is duplicated by")

1 votes, 1 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 5, 2011

Dave Syer commented

I actually like that feature (and it is documented in the blog at least). If <beans/> are allowed anywhere, they are harder to find in an XML file, so right at the top or right at the bottom actually makes sense. On the other hand, it's not very consistent with other schema constraints (e.g. <import/> is allowed anywhere, for good reason).

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 5, 2011

Chris Beams commented

Changing from Bug->Improvement, as this is by design. We implemented the constraint Mark mentions in order to keep chaos to a minimum in XML files, which can already become busy, and also to keep overriding semantics sane.

Dave's comment suggests that one might want to declare <bean> elements after a nested <beans> element in order to override (just like you can with carefully positioned <import> elements). But think about it - would this ever make sense?

<beans>
    <bean id="foo" class="..."/>
    <beans profile="p1">
	      <bean id="foo" class="..."/> <!-- overrides top-level foo -->
        <bean id="bar" class="..."/> <!-- introduces 'bar' for first time -->
    <beans>
    <bean id="bar" class="..."/> <!-- *always* wins, overriding 'bar' even if profile 'p1' is active! -->
</beans>

I'll wait for further feedback, but without use cases that invalidate the above, I'm going to resolve it "won't fix" before 3.1 M2 (in any case, it's good to have this conversation documented, as others will probably wonder the same).

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 26, 2011

Chris Beams commented

Resolving as Won't Fix for reasons mentioned in previous comments

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 16, 2011

Scott Andrews commented

Please reopen.

If you're using a profile to provide alternate implementations of a service, it makes sense for that config to be closer to related bean definitions.

Alternatively, if the profile contains a property placeholder definition, it feels wrong for that definition to be at the bottom of the config when it is normally at the top.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 19, 2011

Chris Beams commented

We'll give this some more thought for 3.1. I'd like to hear additional voices on the matter, as I think the arguments for and against lifting the restriction are strong.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 24, 2012

Piotr Findeisen commented

Having current XSD restrictions leads to unnatural order of beans. Quite often beans are ordered/grouped within beans.xml files (even though the project already uses many beans files), and having to remove a bean from its natural position and move it at the tail of the file makes it less readable.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 24, 2012

Chris Beams commented

Thanks, Piotr. Please vote for the issue. What do you think about the rationale offered by Dave and myself in the Apr 5 comments above? Do you understand the conceptual and practical reasons that have led to this restriction? Do you think that the 'unnatural order' problem you discuss outweighs these concerns? This is a situation where there exists no perfect answer, just tradeoffs. We're been keeping the more conservative approach thus far, because once it's relaxed we cannot go back. Your feedback is appreciated.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 24, 2012

Piotr Findeisen commented

Chris, i've just begun using profiles for selective bean inclusion and i didn't know about overrides.

Dave's and mine comments contradict each other. Dave finds <beans> at the bottom more readable and i find just the opposite, i.e. they are more readable if they're in their natural flow.

Profiles & overrides, i.e. your comment -- this is really a good point and i understand your objects. Since you already said that placing e.g. <bean id="bar"/> after <beans> is possible (just requires use of <import>) -- what do you gain but disallowing same construct within single XML file? Also, one can do without imports and construct application context from multiple XML files (as we do in the project), so ordering of XML elements in a single file does not matter.

(Or, maybe, i don't understand correctly -- profiles & overrides are local thing to the XML file?)

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 6, 2014

Piotr Findeisen commented

Hi again

It's been some time so I forgot about this issue... and today the reality reminded me about this. Again I had to move bean definition to the bottom of the file just because I needed to wrap it in a profile.

Besides, overriding the bean definitions using profiles does not work very well when there are multiple XML files -- e.g. I cannot override a "normal" bean with a "profile" bean if they are not in the same file. As such, the overriding is not useful e.g. in integration tests when I want to reuse application bean wiring but need to replace particular beans.

@spring-projects-issues spring-projects-issues added status: declined type: enhancement in: core labels Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: declined type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants