I have a spring-boot application.
I have 3 properties file:
a property file inside the spring-boot jar - myjar.jar called application.properties (which is package inside the jar)
a property file outside the jar, at the jar location under configurations/global.properties
a property file outside the jar, at the jar location under configurations/java.properties
The problem is, I'm running the following command:
java -Dlogging.config=logback.xml -jar "myjar.jar" spring.config.location=classpath:/application.properties,file:./configurations/global.properties,file:./configurations/java.properties
And I get an exception:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'myApplication': Injection of autowired dependencies failed; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'Data.StoresDb.LakeConnectionString' in value "${Data.StoresDb.LakeConnectionString}"
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:405)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1422)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:594)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517)
at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321)
at org.springframework.beans.fa
in myApplication.java, I have:
#Value("${Data.StoresDb.LakeConnectionString}")
String dataLakeStoreDb;
and in my application.properties I do not have Data.StoresDb.LakeConnectionString, but I do have it in my global.properties, I would expect spring to resolve all files before trying to ser the value Data.StoresDb.LakeConnectionString
You pass the arg/value as a raw Java argument :
java -jar "myjar.jar" spring.config.location=...
The argument will be present in the String[] args of the main class but the Spring environment will not be aware about that.
You have to prefix it with -- to make the argument to be Spring environment aware :
java -jar "myjar.jar" --spring.config.location=...
From the official documentation :
By default SpringApplication will convert any command line option
arguments (starting with “--”, e.g. --server.port=9000) to a property
and add it to the Spring Environment
Or as alternative pass it as a system property :
java -Dspring.config.location=... -jar "myjar.jar"
As a side note : beware spring.config.location overrides the default locations while spring.config.additional-location introduced in Spring Boot 2 adds the specified locations to the default locations.
Related
I have a application-local.yml file inside resources folder. I have some properties like
data: https://xyzw/
I am using this property in a different class
#Service
public class Test {
#Value("${data}")
private String data;
}
When I run the Application.java I get the following error:
Application.main(Application.java:13), exception_class=org.springframework.beans.factory.BeanCreationException, exception_message=Error creating bean with name 'Test': Injection of autowired dependencies failed; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'data' in value "${data}"}","threadID":"main","sourceHost":"H18NPLFI13P0303","logVersion":"1.5","category":"org.springframework.boot.SpringApplication"}
Which is weird. I am not sure why it's not picking the values from the application-local.yml file.
If you start your application with IntelliJ IDEA and want the application-local.yml properties to be used, you need to edit your run configuration so that the local profile is used, else the application-local.yml properties won't be picked up by Spring.
Hello I am trying to package my Spring Boot app into a jar.
I want to deploy this app to AWS Beanstalk and so I will be injecting some variables into application.properties using Environment variables.
spring.data.mongodb.uri=${MONGODB_URI}
spring.data.mongodb.auto-index-creation=true
spring.servlet.multipart.max-file-size=-1
spring.servlet.multipart.max-request-size=-1
CLOUDINARY_URL=${CLOUDINARY_URL}
jwt-secret=${JWT_SECRET}
server.port=5000
However when I run the maven command (mvn clean install), during the package process the code is executed and it is failing stating that
BeanCreationException: Error creating bean with name 'customBeansConfig': Injection of autowired dependencies failed; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'CLOUDINARY_URL' in value "${CLOUDINARY_URL}"
I have a class CustomBeansConfig:
#Configuration
public class CustomBeansConfig {
#Value("${CLOUDINARY_URL}")
private String cloudinaryUrl;
#Bean
public Cloudinary cloudinary(){
System.out.println("cloudinaryUrl = " + cloudinaryUrl);
return new Cloudinary(cloudinaryUrl);
}
}
Please help me to create the jar file
If I have understood you correctly, one approach may be to use different application.properties files for different environments. For example application-dev.properties for the Dev environment and application-prod.properties for the Prod environment. Then your CLOUDINARY_URL may be assigned different literal values appropriate to each.
Then when deploying to each environment, bundle your JAR with the -Denv option, as in
mvn -Denv=dev clean install
OR
mvn -Denv=prod clean install
... and upload the resulting JAR file to the corresponding AWS environment.
Running the Spring Boot application with a such config property, got me the following error:
Caused by: java.lang.IllegalArgumentException: Circular placeholder reference 'CLOUDINARY_URL' in property definitions
Changing the name of your Spring property from CLOUDINARY_URL to, for example, cloudinary.service.url will resolve the issue.
In such case, your config file should look like this:
spring.data.mongodb.uri=${MONGODB_URI}
spring.data.mongodb.auto-index-creation=true
spring.servlet.multipart.max-file-size=-1
spring.servlet.multipart.max-request-size=-1
cloudinary.service.url=${CLOUDINARY_URL}
jwt-secret=${JWT_SECRET}
server.port=5000
And your configuration file like this:
#Configuration
public class CustomBeansConfig {
#Value("${cloudinary.service.url}")
private String cloudinaryUrl;
#Bean
public Cloudinary cloudinary(){
System.out.println("cloudinaryUrl = " + cloudinaryUrl);
return new Cloudinary(cloudinaryUrl);
}
}
Also, I would advise you to avoid creating Spring configuration properties using the underscore format, since it usually used for the environment variables, maybe be confusing and may cause such interesting issues.
I am using Spring boot application and having application.properties property file in src/main/resources. It has some properties which needs to replaced by external property file. I will pass the external file location in command line.
Need solution how to replace the properties inside application with external properties.
public static void main(String[] args) throws JMSException, MQException, IOException {
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
InputStream input = classLoader.getResourceAsStream("Application.properties");
Properties properties = new Properties();
properties.load(input);
properties.load(new FileReader(args[0]));
SpringApplication springApplication = new SpringApplication(new Object[]{ChapsSchemeFeed.class});
springApplication.setDefaultProperties(properties);
springApplication.run(args);
}
In this code, I am reading properties from command line and loading them with application.properties residing in application. But when I start, its loading properties from Application.properties. But I want to replace it with property from command line properties file.
From the Spring Boot manual:
Spring Boot uses a very particular PropertySource order that is designed to allow sensible overriding of values. Properties are considered in the following order:
Devtools global settings properties in the $HOME/.config/spring-boot folder when devtools is active.
#TestPropertySource annotations on your tests.
properties attribute on your tests. Available on #SpringBootTest and the test annotations for testing a particular slice of your application.
Command line arguments.
Properties from SPRING_APPLICATION_JSON (inline JSON embedded in an environment variable or system property).
ServletConfig init parameters.
ServletContext init parameters.
JNDI attributes from java:comp/env.
Java System properties (System.getProperties()).
OS environment variables.
A RandomValuePropertySource that has properties only in random.*.
Profile-specific application properties outside of your packaged jar (application-{profile}.properties and YAML variants).
Profile-specific application properties packaged inside your jar (application-{profile}.properties and YAML variants).
Application properties outside of your packaged jar (application.properties and YAML variants).
Application properties packaged inside your jar (application.properties and YAML variants).
References:
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
I'm developing a spring boot application(Let's call this MyLib). It uses spring-cloud-stream. The idea is that this application will be used as a jar by another java application(Let's call this MyApp. It may not be a spring boot). What I'm trying to do is that MyApp will specify the spring.cloud.stream.bindings.<channel>.destination which will be used by the code inside MyLib.
Is this achievable?
Load application.properties from an external jar
I don't know about spring.cloud.stream.bindings specifically, however a spring Boot application can load its application-${profile}.properties from multiple locations including jars on the classpath:
Spring Boot documentation:
SpringApplication will load properties from application.properties
files in the following locations and add them to the Spring
Environment:
A /config subdirectory of the current directory.
The current directory
A classpath /config package
The classpath root
The list is ordered by precedence (properties defined in locations
higher in the list override those defined in lower locations).
...
The default search path
classpath:,classpath:/config,file:,file:config/ is always used,
irrespective of the value of spring.config.location
In other words, the application-${profile}.properties file must be at ./ or ./config/ inside your MyApp.jar.
You may also define additional lookup folders with spring.config.location, however this must be done at runtime:
spring.config.name and spring.config.location are used very early to determine which files
have to be loaded so they have to be defined as an environment
property (typically OS env, system property or command line argument).
Lookup order
You mentioned
:
Overriding spring properties in application.properties
The order with which the properties are considered is the following (from spring documentation):
#TestPropertySource annotations on your tests.
Command line arguments.
Properties from SPRING_APPLICATION_JSON (inline JSON embedded in an environment variable or system property)
ServletConfig init parameters.
ServletContext init parameters.
JNDI attributes from java:comp/env.
Java System properties (System.getProperties()).
OS environment variables.
A RandomValuePropertySource that only has properties in random.*.
Profile-specific application properties outside of your packaged jar (application-{profile}.properties and YAML variants)
Profile-specific application properties packaged inside your jar (application-{profile}.properties and YAML variants)
Application properties outside of your packaged jar (application.properties and YAML variants).
Application properties packaged inside your jar (application.properties and YAML variants).
#PropertySource annotations on your #Configuration classes.
Default properties (specified using SpringApplication.setDefaultProperties).
The problem is that, the jar file uses Spring ORM for loading the persistance configurations, and based on these configurations, files are moved to suitable folders in HDFS. Now If i use, 'java -cp' instead of 'hadoop jar', it fails to copy to HDFS, with FileSystem error.
While invoking the jar with hadoop jar command (having spring orm injected) the exception is as:
Exception in thread "main" org.springframework.beans.factory.BeanCreationException: Error creating bean with name
'org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor#0'
defined in class path resource [applicationContext.xml
Error creating bean with name 'entityManagerFactory' defined in class
path resource [applicationContext.xml]: Invocation of init method
failed; nested exception is java.lang.IllegalStateException:
Conflicting persistence unit definitions for name 'Persistance':
file:/home/user/Desktop/ABC/apnJar.jar,
file:/tmp/hadoop-ABC/hadoop-unjar2841422106164401019/
Caused by: java.lang.IllegalStateException: Conflicting persistence
unit definitions for name 'Persistance'
Seems like Hadoop is unpacking the jar file to some tmp folder, is this really required?
Can we skip this step by any configuration change?
Any thoughts on this are welcome.
If you use "hadoop jar", hadoop will run org.apache.hadoop.util.RunJar. RunJar will unpackage your jar into a temp folder(In your case is /tmp/hadoop-ABC/hadoop-unjar2841422106164401019/) and load it in the current class loader. At last, it will invoke your main class to run your MapReduce application.
Did you add your jar in the CLASSPATH? If so, you will have your jar and the unpackaged folder in the class loader. I think that's why spring complains it.
As a work around, I extracted the configuration xmls from the jar, and placed them in the working directory.
This worked, however looking for the proper solution.
Hence If you are facing the similar issue, remove all configuration xmls and place the jar with only the compiled class files.