I'm training about the combo Restlet/Spring but there are some things i still don't understand... I hope you can help me.
In fact, i'm trying to the use Inject dependancies systeme of Spring with Restlet (Like in this tutorial : http://restlet.com/technical-resources/restlet-framework/guide/2.3/introduction/getting-started/maven-spring). So I tried to do it myself but that didn't work. My code returns this exception :
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'basecampComponent' defined in ServletContext resource [/WEB-INF/applicationContext.xml]:
Cannot resolve reference to bean 'basecampAppliction' while setting bean property 'defaultTarget'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'basecampAppliction' defined in ServletContext resource [/WEB-INF/applicationContext.xml]:
Error setting property values; nested exception is org.springframework.beans.NotWritablePropertyException: Invalid property 'root' of bean class[com.mycompany.restlet.basecamp.application.BaseCampApplication]:
Bean property 'root' is not writable or has an invalid setter method. Does the parameter type of the setter match the return type of the getter?
So i was looking for the file "ApplicationContext.xml" and this is his content :
<bean id="basecampComponent" class="org.restlet.ext.spring.SpringComponent">
<property name="defaultTarget" ref="basecampAppliction" />
</bean>
<bean id="basecampAppliction">class="com.mycompany.restlet.basecamp.application.BaseCampApplication">
<property name="root" ref="router" />
</bean>
<!-- Define the router -->
<bean name="router" class="org.restlet.ext.spring.SpringBeanRouter" />
Someone has an idea where could I look for a way to debug this ?
By the way, i'm in Java 1.8.0_60.
Thanks for all your helps.
Benjamin
After looking for some informations over the web, i've a hypothesis how I solved this.
On this link (Spring & Restlet : 100% XML configuration?), he's binding the router with the property "inboundroot" of Application. So I think there's a minimal changed (not noticed in the tutorial). In fact, i tried the project proposed in the archive (doesn't work) and the way you code yourself the tutorial. This is again two solutions.
The final solution consists so by changing the name of the property to "inboundroot" to "root".
"Never trusts the tuto"
Thanks for the time you took to help me.
I think that there is no root attribute in the Application class. You should add one in your BaseCampApplication class and use it to configure your application (see createInboundRoot method), as described below:
public class BaseCampApplication extends Application {
private Restlet root;
public Restlet createInboundRoot() {
return root;
}
public void setRoot(Restlet root) {
this.root = root;
}
}
Hope it helps you,
Thierry
I am using Spring Boot.
I declared properties in an external file outside the classpath.
I added that to one of my XML files:
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="ignoreUnresolvablePlaceholders" value="true" />
<property name="ignoreResourceNotFound" value="true" />
<property name="locations">
<list>
<value>file:///d:/etc/services/pushExecuterService/pushExecuterServices.properties</value>
</list>
</property>
</bean>
However, I still get this error:
Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'configuration.serviceId' in string value "${configuration.serviceId}"
at org.springframework.util.PropertyPlaceholderHelper.parseStringValue(PropertyPlaceholderHelper.java:174)
I added a breakpoint in the PropertiesLoaderSupport class at this method:
public void setLocations(Resource... locations) {
this.locations = locations;
}
I paid attention that this method invoked multiple times and in one of them I noticed the locations param populated with:
URL [file:/d:/etc/services/pushExecuterService/pushExecuterServices.properties]
However, I am still getting this error.
I double checked in my project and I dont have any additional PropertyPlaceholderConfigurer beans(didnt check on external dependencies)
I ran my app with hard code the params inside the xml I can see within spring-boot logs:
2015-01-05 18:56:52.902 INFO 7016 --- [ main]
o.s.b.f.c.PropertyPlaceholderConfigurer: Loading properties file from
URL [file:/d:/etc/services/pushExecuterService/pushExecuterServices.properties]`
So I am not sure what's happening. any leads?
thank you.
Spring Boot favors Java-based configuration. In order to add configuration properties, we can use #PropertySource annotation together with #Configuration annotation.
The properties can be stored in any file. Property values can be injected directly into beans using the #Value annotation:
#Configuration
#PropertySource("classpath:mail.properties")
public class MailConfiguration {
#Value("${mail.protocol}")
private String protocol;
#Value("${mail.host}")
private String host;
}
#PropertySource's value attribute indicate the resource location(s) of the properties file to be loaded. For example, "classpath:/com/myco/app.properties" or "file:/path/to/file"
But Spring Boot provides an alternative method of working with properties that allows strongly typed beans to govern and validate the configuration of your application: #ConfigurationProperties
See this blog post with an example of using #ConfigurationProperties: http://blog.codeleak.pl/2014/09/using-configurationproperties-in-spring.html
For the #PropertySource example you can check this article: http://blog.codeleak.pl/2014/09/testing-mail-code-in-spring-boot.html
I am having difficulty understanding why something in Spring Java Config using #Autowired does not work.
First, I am trying to move all my #Autowired annotations in the Java Config classes. This has the effect of making my "POJOs" back into real POJOs. I can then not only test them easily outside of a Spring context, but can also use mock objects easily and readily.
So I first tried this:
#Configuration
public class Module3ConfigClass {
#Autowired
private Module1Bean1 module1Bean1;
#Autowired
private Module2Bean1 module2Bean1;
#Bean
public Module3Bean1 module3Bean1() {
return new Module3Bean1(module1Bean1, module2Bean1);
}
}
However, when the Module3Bean1 constructor is invoked, both passed in Beans are null. If you didn't follow my made up naming convention above, both of those beans would be created by a separate Java Config configuration file. Also note that everything is wired up correctly - I know this because everything works perfectly when the #Autowired tags are on the corresponding private member fields inside of Module3Bean1.
FWIW, I tried adding an #DependsOn annotation to module3Bean1() method, but had the same results. I guess I just would really like to understand this behavior, is it correct (I suspect it is, but why)?
Finally, I found an acceptable workaround shown here:
#Configuration
public class Module3ConfigClass {
#Bean
#Autowired
public Module3Bean1 module3Bean1(Module1Bean1 module1Bean1, Module2Bean1 module2Bean1) {
return new Module3Bean1(module1Bean1, module2Bean1);
}
}
This seems fine to me, but if anyone would care to comment on it, that would be welcome as well.
I think you came across same problem I just had. In my case problem was invalid xml configuration. In my module B I had config like :
<beans>
<context:component-scan base-package="com.moduleB"/>
<import resource="classpath:applicationContext-moduleA.xml"/>
</beans>
In moduleA context I placed "context:annotation-config" annotation.
When I change import/context order to :
<beans>
<import resource="classpath:applicationContext-moduleA.xml"/>
<context:component-scan base-package="com.moduleB"/>
</beans>
Autowiring for configuration class properties started to work.
We had the same issue and came to the conclusion that the error arose because we had a circular dependency where a BeanPostProcessor was involved.
A PropertyPlaceholderConfigurer (a BeanPostProcessor) has been configured to set its propertiesArray property with the help of another bean:
<bean id="globalPropertyPlaceholderConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"
lazy-init="false" depends-on="javaLoggingConfigurer">
<property name="locations">
<list>
<value>classpath:config/host/${env.instance}.properties</value>
<value>WEB-INF/config/host/${env.instance}.properties</value>
</list>
</property>
<property name="ignoreResourceNotFound" value="true" />
<property name="propertiesArray" value="#{springPropertyFinder.findProperties()}" />
</bean>
The used springPropertyFinder bean to set the propertiesArray is not a BeanPostProcessor but a "normal" bean that gathers all Properties instances with:
public Properties[] findProperties() {
Map<String, Properties> propertiesMap = applicationContext.getBeansOfType(Properties.class);
for (String title : propertiesMap.keySet()) {
PropertiesLoggerUtil.logPropertiesContent(logger, "Springcontext Properties ("+title+")", propertiesMap.get(title));
}
return propertiesMap.values().toArray(new Properties[propertiesMap.size()]);
}
The #Configuration class contained a bean of type Properties
So our assumption is that the #Configuration class has been created without being processed by the ConfigurationClassPostProcessor (also a BeanPostProcessor), because the PropertyPlaceholderConfigurer depends on the springPropertyFinder, which depends on the properties bean in the #Configuration class. The order of the BeanPostProcessors is probably not setup right under these circumstances.
This described setup worked in XML, but not with Java config.
here is a blog of Spring:
http://blog.springsource.org/2011/02/15/spring-3-1-m1-unified-property-management/
it introduce a new feature: user placeholder in import tag.
example: <import resource="com/bank/service/${customer}-config.xml"/>
well, I'm 3.1 too.
and then, when i start MYAPP, the miracle did not happen..
here is my code:
(config.properties in sourceFolder):
kName = P0765
(spring's xml):
<bean id="placeholderConfig" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">;
<property name="location" value="classpath:config.properties" >;
</bean>
<import resource="readyData/${KName}.xml"/>
:(
What work did not do？？
Properties that are resolved in the import element have to be set as a JVM system property or system environment variable. It is described in the blog post you linked here.
This is because merging Spring configuration files happens before initializing beans (PropertyPlaceholderConfigurer is a bean) at it probably won't change, see this rejected feature request https://jira.springsource.org/browse/SPR-1358
In my Spring xml configuration I'm trying to get something like this to work:
<beans>
<import resource="${file.to.import}" />
<!-- Other bean definitions -->
</beans>
I want to decide which file to import based on a property in a properties file.
I know that I can use a System property, but I can't add a property to the JVM at startup.
Note: The PropertyPlaceHolderConfigurer will not work. Imports are resolved before any BeanFactoryPostProcessors are run. The import element can only resolve System.properties.
Does anyone have a simple solution to this? I don't want to start subclassing framework classes and so on...
Thanks
This is, unfortunately, a lot harder than it should be. In my application I accomplished this by doing the following:
A small, "bootstrap" context that is responsible for loading a PropertyPlaceholderConfigurer bean and another bean that is responsible for bootstrapping the application context.
The 2nd bean mentioned above takes as input the "real" spring context files to load. I have my spring context files organized so that the configurable part is well known and in the same place. For example, I might have 3 config files: one.onpremise.xml, one.hosted.xml, one.multitenant.xml. The bean programmatically loads these context files into the current application context.
This works because the context files are specified as input the the bean responsible for loading them. It won't work if you just try to do an import, as you mentioned, but this has the same effect with slightly more work. The bootstrap class looks something like this:
public class Bootstrapper implements ApplicationContextAware, InitializingBean {
private WebApplicationContext context;
private String[] configLocations;
private String[] testConfigLocations;
private boolean loadTestConfigurations;
public void setConfigLocations(final String[] configLocations) {
this.configLocations = configLocations;
}
public void setTestConfigLocations(final String[] testConfigLocations) {
this.testConfigLocations = testConfigLocations;
}
public void setLoadTestConfigurations(final boolean loadTestConfigurations) {
this.loadTestConfigurations = loadTestConfigurations;
}
#Override
public void setApplicationContext(final ApplicationContext applicationContext) throws BeansException {
context = (WebApplicationContext) applicationContext;
}
#Override
public void afterPropertiesSet() throws Exception {
String[] configsToLoad = configLocations;
if (loadTestConfigurations) {
configsToLoad = new String[configLocations.length + testConfigLocations.length];
arraycopy(configLocations, 0, configsToLoad, 0, configLocations.length);
arraycopy(testConfigLocations, 0, configsToLoad, configLocations.length, testConfigLocations.length);
}
context.setConfigLocations(configsToLoad);
context.refresh();
}
}
Basically, get the application context, set its config locations, and tell it to refresh itself. This works perfectly in my application.
Hope this helps.
For the Spring 2.5 and 3.0, I have a similar solution to louis, however I've just read about 3.1's upcoming feature: property management, which sounds great too.
There is an old issue on the Spring JIRA for adding properties placeholder support for import (SPR-1358) that was resolved as "Won't Fix", but there has since been a proposed solution using an EagerPropertyPlaceholderConfigurer.
I've been lobbying to have SPR-1358 reopened, but no response so far. Perhaps if others added their use cases to the issue comments that would help raise awareness.
Why not:
read your properties file on startup
that will determine which Spring config to load
whichever Spring config is loaded sets specific stuff, then loads a common Spring config
so you're effectively inverting your current proposed solution.
Add something similar to the following:
<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="ignoreResourceNotFound"><value>true</value></property>
<property name="locations">
<list>
<value>classpath:propertyfile.properties</value>
</list>
</property>
</bean>
If what you want is to specify the imported XML file name outside applicationContext.xml so that you could replace applicationContext.xml without losing the configuration of the imported XML file path, you can just add an intermediate Spring beans XML file, say, confSelector.xml, so that applicationContext.xml imports confSelector.xml and confSelector.xml only contains an <import> element that refers to the suitable custom beans XML file.
Another means that might be of use are XML entities (defined by adding <!ENTITY ... > elements into the DTD declaration at the beginning of XML). These allow importing XML fragments from other files and provide "property placeholder"-like functionality for any XML file.
Neither of these solutions allows you to have the configuration file in Java's .properties format, though.
André Schuster's answer, which I bumped, helped me solve a very similar issue I was having in wanting to find a different expression of properties depending on whether I was running on my own host, by Jenkins on our build host or in "real" deployment. I did this:
<context:property-placeholder location="file:///etc/myplace/database.properties" />
followed later by
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>WEB-INF/classes/resources/database.properties</value>
...
</list>
</property>
</bean>
which solved my problem because on my development host, I put a link to my own copy of database.properties in /etc/myplace/database.properties, and a slightly different one on the server running Jenkins. In real deployment, no such file is found, so Spring falls back on the "real" one in resources in my class files subdirectory. If the properties in question have already been specified by the file on /etc/myplace/database.properties, then (fortunately) they aren't redefined by the local file.
Another workaround which does not rely on system properties is to load the properties of all the files using a different PropertyPlaceholderConfigurer for each file and define a different placeholderPrefix for each of them.
That placeholderprefix being configured by the initial property file.
Define the first property file: (containing either first or second)
global.properties
fileToUse=first
Define the files containing a property that can be switched depending on the property defined just above:
first.properties
aProperty=propertyContentOfFirst
second.properties
aProperty=propertyContentOfSecond
Then define the place holders for all the files:
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>classpath:global.properties</value>
</list>
</property>
</bean>
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="placeholderPrefix" value="first{" />
<property name="locations">
<list>
<value>classpath:first.properties</value>
</list>
</property>
</bean>
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="placeholderPrefix" value="second{" />
<property name="locations">
<list>
<value>classpath:second.properties</value>
</list>
</property>
</bean>
Use the property defined in global to identify the resource to use from the other file:
${fileToUse}{aProperty}
If I add the JVM argument below and have the file myApplicationContext.dev.xml, spring does load
-DmyEnvironment=dev
<context:property-placeholder />
<import resource="classpath:/resources/spring/myApplicationContext.${myEnvironment}.xml"/>
I'm using Spring 3 and load a properties like that:
<context:property-placeholder location="/WEB-INF/my.properties" />