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

${...} placeholders support for import only works on system properties [SPR-1358] #6058

Closed
spring-issuemaster opened this issue Oct 6, 2005 · 10 comments

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Oct 6, 2005

Joe Shomphe opened SPR-1358 and commented

Please see comments on #6032 for more information


Affects: 1.2.6

4 votes, 16 watchers

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Oct 6, 2005

Juergen Hoeller commented

This is by design. Imports are processed before any beans get instantiated, even before BeanFactoryPostProcessors such as PropertyPlaceholderConfigurer. Hence, placeholders in import locations cannot be resolved by a PropertyPlaceholderConfigurer, at least not without a major change in the BeanFactory architecture.

Juergen

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 31, 2006

Alex Wei commented

An EagerPropertyPlaceholderConfigurer coud provide the required function. Please see the related issue:
http://opensource.atlassian.com/projects/spring/browse/SPR-1076

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Sep 11, 2008

Ian Brandt commented

Any chance of reviving this issue with the EagerPropertyPlaceholderConfigurer? Imports based on property file settings would be a nice and familiar way to configure "sub-contexts" for different environments. I generally try to avoid global system properties in favor of containable properties files. It would be nice to consolidate the environment definition into one place, including when different context configurations are required.

A basic use case for justification purposes is that in my development environment I use SimpleTriggerBean to fire Quartz jobs immediately, but in QA and various production environments I use different CronTriggerBean configurations. I'd also imagine SpringIDE could be made to load and resolve the properties when doing imports during bean validation, which would be a nice feature as well.

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Apr 6, 2010

Ian Brandt commented

I just "rediscovered" this issue over a year later. There has also been a related stackoverflow question:

http://stackoverflow.com/questions/1520055/import-spring-config-file-based-on-property-in-properties-file

So I'm making another appeal to reopen?...

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Apr 6, 2010

Ian Brandt commented

Digging into the 3.0.2.RELEASE source I'm now not seeing how Alex's EagerPropertyPlaceholderConfigurer could resolve this issue after all? Per Juergen's initial comment it seems that DefaultBeanDefinitionDocumentReader.importBeanDefinitionResource(Element) creates the import Resource, parses it, and registers its bean definitions—meaning placeholders need to have been already substituted—prior to any BeanFactoryPostProcessor or InitializingBean hooks being called. It appears that even a BeanDefinitionRegistryPostProcessor would be too late.

The only hook I've seen so far that would happen in time is DefaultBeanDefinitionDocumentReader.preProcessXml(Element root). I suppose you could:

  1. Search the DOM for PropertyPlaceholderConfigurer declarations.
  2. Load the specified properties (one way or another).
  3. Search the DOM for import statements.
  4. Replace the location placeholders in the DOM before DefaultBeanDefinitionDocumentReader.registerBeanDefinitions is ever called.

\
I've got all of about an hour's worth of experience with BeanFactory internals, but that approach sounds like it would be a pretty undesirable patch to me. I'll keep searching the source to try to understand whether there are any other hooks that could otherwise do the job. If you could initialize a bean right at definition registration time then—so long as it was declared in the config prior to any imports—perhaps it could make property file placeholder substitution available to <import />. A well known bean could do so statically just like SystemPropertyUtils.resolvePlaceholders(location) does for system properties, or maybe SpEL could be made available during the parsing phase to perform such substitutions.

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Apr 17, 2010

Dave Syer commented

#9578 is basically the same feature request, and it is in the roadmap for 3.1. We haven't decided how to do it yet but there is some prototype code in a branch. Can I suggest you transfer your attention to that issue?

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Sep 24, 2012

joerg.hohwiller@googlemail.com commented

Its a real pitty that this issue has been rejected. I wanted to do this:

<import resource="classpath:net/sf/mmm/persistence/beans-persistence-datasource-${persistence.datasource}.xml"/>
<import resource="classpath:net/sf/mmm/persistence/beans-persistence-jpa-${persistence.jpa.vendor}.xml"/>

e.g. with beans-persistence-datasource-c3p0.xml:

<bean id="javax.sql.DataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
<property name="user" value="${persistence.jdbc.user}"/>
<property name="password" value="${persistence.jdbc.password}"/>
<property name="driverClass" value="${persistence.jdbc.driver}"/>
<property name="jdbcUrl" value="${persistence.jdbc.url}"/>
<property name="initialPoolSize" value="0"/>
<property name="maxPoolSize" value="${persistence.jdbc.pool.max}"/>
<property name="minPoolSize" value="${persistence.jdbc.pool.min}"/>
<property name="acquireIncrement" value="${persistence.jdbc.pool.increment}"/>
<property name="acquireRetryAttempts" value="0"/>
<property name="autoCommitOnClose" value="false"/>
<property name="maxStatements" value="${persistence.jdbc.maxStatements}"/>
<property name="maxStatementsPerConnection" value="${persistence.jdbc.maxStatementsPerConnection}"/>
<property name="statementCacheNumDeferredCloseThreads" value="${persistence.jdbc.statementCacheNumDeferredCloseThreads}"/>
</bean>

and beans-persistence-datasource-spring.xml:
<bean id="javax.sql.DataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="${persistence.jdbc.driver}"/>
<property name="url" value="${persistence.jdbc.url}"/>
<property name="username" value="${persistence.jdbc.username}"/>
<property name="password" value="${persistence.jdbc.password}"/>
</bean>

I can not join such XML config variants to a single XML. And there is also no way to load the properties as system-properties in all containers. Therefore I would need to declare them outside of the properties file on every call (including every JUnit test). This is reducing a lot of the flexibility of springframework :(

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 22, 2013

Alexey Borschenko commented

This feature is still not implemented.

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Sep 8, 2014

Brett Ryan commented

Is there any plan to implement this? If not, is there any way to return an empty string if the value is not set?

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.