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

Ignore duplicated import files or property-placeholder files [SPR-9526] #14160

Closed
spring-issuemaster opened this Issue Jun 20, 2012 · 4 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

spring-issuemaster commented Jun 20, 2012

Jay Blanton opened SPR-9526 and commented

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.

The example from this thread:
http://forum.springsource.org/showthread.php?36482-Preventing-Spring-Context-to-be-loaded-more-than-once&highlight=duplicate+context+files

Is a perfect example:
http://piotrga.wordpress.com/2007/03/21/preventing-spring-context-to-be-loaded-more-than-once/

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.
http://stackoverflow.com/questions/8949174/does-spring-ignore-duplicate-property-placeholder-files

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.


Affects: 3.0.5

Reference URL: http://forum.springsource.org/showthread.php?36482-Preventing-Spring-Context-to-be-loaded-more-than-once&highlight=duplicate+context+files

Issue Links:

  • #16379 Multiple bean instances are created when no id is specified ("is duplicated by")
  • #5845 Load files in only once

10 votes, 7 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Nov 21, 2013

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.
This would also greatly simplify supporting multiple main application contexts and conditional activation of parts of application with spring profiles.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Jun 10, 2015

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.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Jun 11, 2015

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 talked to someone who is familiar with dagger, he told me that in dagger, the modules resolve theirselves' injections, which means:
moduleA is the instances injected by using configA, moduleB is the instances injected by using configB)

I know there might be some problems, for instance, there modules A, B, C A depends on B, C, B depends on C
B resolve the injection of C by using config One, if A wants to resolve injection for C by using config Two, what is supposed to do?

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?)

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Jan 12, 2019

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment