I have a spring-boot application with annotations instead of context.xml.
In my src/main/resources folder I have: application-dev.properties and application-test.properties.
which work perfectly for different profiles (while running with VM option like -Dspring.profiles.active=dev)
Now I need to externalize this properties with file in /opt/software/Tomcat8/conf/app.properties
Some props override each other, some don't.
in Tomcat config context.xml I say:
<Environment name="app.properties"
value="file:///opt/software/Tomcat8/conf/app.properties"
type="java.lang.String" override="false"/>
How to use it via JNDI in my application configuring app with no XML but annotations in Spring-bot application class?
I need it to have priority to inner jar properties according to
Link to Spring-boot.doc
One solution I found was to have the vm argument -Dloader.path with the external path when executing the application. Please keep in mind if you're using a fat jar you may need to create the package in Zip model, otherwise it will not work.
Related
I have two issues when I work with springboot 1.5.4, I can not resolve them.
Issue No 1.
I configured the logback-spring.xml in src/main/resources，when spring boot started, two directories will be created, one is started with 'application name', the another one is started with bootstrap..
i was confused why bootstrap log file directory created, spring boot created two log directories, by the way, spring maybe loaded the logback-spring.xml two times when it started.
Issue No 2.
I have many projects, some same configures need to copy to application file in every project, and I want to put some common properties in a common files.
How to refenrence a common config file or include it ?
Is there a usage in spring boot application.yml like below:
spring.xx.inclue: ../common-project/config/common.yml
Thanks.
About the spring.application.name being in bootstrap file, isn't really necessary. you can declare a spring property:
<springProperty name="applicationName" source="spring.application.name" defaultValue="UNKNOWN_APP"/>
I think this makes easier the idea of getting a common.yml that is not really needed.
But if for some reason you want that, you can use property feature:
<property resource="commons.yml" />
I use maven. My web application contains two modules and each has it's own spring context. First is packed to jar, the second one to war. The second one uses first module's jar and calls it's methods.
I need to add property file, which will be used by first module (via spring context). The main issue is that I should be able to access/edit this property file after war deployment.
How can I provide such a property file, that will be used in first jar module and can be changed after war module deployment?
Thanks.
Sorry, don't see the problem, you need to describe that better. From what I understood this is the way to go:
place a.properties in src/main/resources in the JAR module
use a PropertyPlaceholderConfigurer to make the properties available in the Spring context
it'll be packed in root of the JAR
the JAR ends up in WEB-INF/lib of the WAR which again is "root of the classpath" so to speak
Update, 2013-06-09
(question was updated based on comments to initial answer above)
Essentially what you seem to be looking for (still not quite sure) is how to load properties from a properties file that is not packaged with your WAR/JAR.
In this case you can skip all of the above steps except 2.
Use a PropertyPlaceholderConfigurer and specify the location of the file as classpath*:a.properties (see below)
Place a.properties anywhere on the classpath outside the WAR file.
Warning! Of course you can now edit the properties independently from releasing the WAR file but since Spring initializes the beans on application start and since all beans are singletons by default changes to the properties file won't become effective until you restart the app.
XML example
<bean class="....PropertyPlaceholderConfigurer">
<property name="location" value="classpath*:a.properties" />
I'm probably thinking about this incorrectly, but here's what I'm up against:
I'm injecting Spring Resource objects into my app that give me the location of security certificates, for example:<property name="certificateResource" value="SomeCert.p12" /> where certificateResource is of type org.springframework.core.io.Resource
Running under JUnit the Resource is a classpath resource and everything is fine. When deployed as a war under Tomcat the the Resource is in a Servlet Context and requires WEB-INF/classes/ prepended to the certificate.
I've tried a number of Resource prefix and wildcard combinations but can't come-up with a single string that satisfies both contexts. So far the "solution" is to override the bean definition in src/test/resources/test-applicationContext.xml but that means maintaining the strings in two locations.
Any pointers to better solutions would be appreciated, thanks.
I have tried to make a small but descriptive application using spring-test and spring-webmvc and using resources referenced in xml configs while these xml's are reused by production and testing spring configurations. Here is what I recieved: github.com/isopov/spring-resource-test
The central is the referencing of the prodcution xml config from the testing config:
<import resource="file:src/main/webapp/WEB-INF/applicationContext.xml" />
it is also possible to not import one xml from the other, but give each test several configs:
#ContextConfiguration(locations = { "classpath:test-applicationContext.xml",
"file:src/main/webapp/WEB-INF/applicationContext.xml" })
the resource itself resides in src/main/resources (I assumed you are using Maven or something derived from the "Standard Directory Layout") so is always accessible with "classpath:hello.txt" from any spring config.
I tested this with maven build, as web-application and running UTs inside Eclipse.
I have a Spring config file with one bean. The bean has 2 properties that are populated from a properties file. I am using the following config in my Spring file to copy the values in but it does not seem to be working.
<context:property-placeholder ignore-resource-not-found="true"
system-properties-mode="NEVER"
location="classpath:my.properties"/>
The weird thing is - this has worked before. Can anyone tell me why this would not be successful in copying the properties across?
I know the infomation given is scant. I'll add elaborate if needs be.
Try the classpath*: prefix. And try giving the relative path to the conf file, and make sure it is really on the classpath (note that WEB-INF is not on the classpath - the classpath of a webapp starts at WEB-INf/classes (and lib))
I am trying to get Spring working with tomcat JNDI resource to access my database. My project works if a META-INF/context.xml in my project with the resource information but once I remove it it stops.. why.
If you deploy a Web application in Tomcat, in the deployment process, Tomcat will copy the META-INF/context.xml file in $CATALINA_HOME/conf/ so the context will be available for your application. Take in mind, that if you remove context.xml from you application because you dont want it, you also have to delete it manually from $CATALINA_HOME/conf/
If you have edited the server.xml for including your dababase resource and is not working when you remove context.xml it could be because you made some mistake defining your resourde in server.xml
UPDATED:
When resource is in server.xml, in context you should make a reference to global resource in server.xml. For example:
<Context crossContext="true" reloadable="true" >
<ResourceLink name="jdbc/myApp" type="javax.sql.DataSource" global="jdbc/myApp" />
</Context>
This is unrelated to Spring.
To use JNDI you are expected to define the various resources either as global configuration or as application specifici configuration. For example JNDI DataSource Configuration
Why do you expect it to work in any other case? How would Tomcat know which resources to provide if you don't define them?
UPDATE:
You define a resouce in your server.xml but you have to associate the resource with your web application. That is why you also need to modify context.xml