Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Ignore duplicated import files or property-placeholder files [SPR-9526] #14160
We have a web service architecture where any service (API - Int/Impl) could be exposed as a web service. Because of this we have very granular deployment artifacts where each service builds down to a JAR. That way we can pick and chose what JARs create a web service implementation (into a WAR). Because of this we have duplicated property file imports and context file imports, but we know it is going to happen because each individual service needs to be buildable, runnable, and testable...and then it might be composed into a larger service.
We might Service B (which is it's own WAR), Service C (which is it's own WAR), and also a Service A (which has dependencies on Service B/C) and therefore pulls in duplicate import statements for the same context file.
The following is a post that I made, without a response, describing the same issue with the property-placeholder.
Since we are aware of the duplicates, we don't want to have exceptions thrown when encountering duplicate bean ids. We don't receive these errors/issues, but we can see that the duplicate files are loaded and override each other.
It would be beneficial if both the import and property-placeholder had the capability to ignore-duplicate-files, or via a property in a custom ApplicationContext (like we extend XmlWebApplicationContext) which would allow the ignore-duplicate-files for properties or bean context files.
10 votes, 7 watchers
Vadim Kopichenko commented
This feature would be very convenient to handle transitive dependencies in multi-module projects.
Currently spring forces us to explicitly import in the main application context all submodules' contexts and contexts of their third-party dependencies.
Alternatively, we could allow submodules to import their own context dependencies in their own context.
Then any client module could import just contexts of modules it directly depends on without bothering with transitive dependencies.
Lucian Yao commented
The feature is very helpful in our projects. We have several modules with spring framework. some depend on others. without importing, we have to fix a lot of errors at runtime, duplicate many lines of xml config at the top modules. This kind of job take a lot of time, and unnecessary. It is really painful. Even worse, if the lower-level modules change their dependencies(like refactoring), the configs of every upper-level modules have got to be changed.
Lucian Yao commented
Surely, if we let the lower-level module resolve its own injection, it will lose the flexibility that we can change the implementation at the high level. but in most cases I think, the injection should be resolved at some level, the top level doesn't need take care of injection at every level.
I know there might be some problems, for instance, there modules A, B, C A depends on B, C, B depends on C
Or if B resolves the injection of C (or even C resolves its own injection), can A replace the injection for C(by some kind of overriding?)