I have a java file where a variable taken value at run time.I search for a service using web service discovery and keep its url in a variable.
Now I need to pass this value to pom.xml.
abc.java has code with
String url= http://xx.xx.xx.xx:55939/ABCDevice?wsdl
Pom.xml is:
<wsdlOptions>
<wsdlOption>
<wsdl>url</wsdl> <!-- get urlvalue from java file -->
<wsdlLocation>classpath:com/admin/discovery/ABCService.wsdl
</wsdlLocation>
</wsdlOption>
</wsdlOptions>
In wsdl i want to pass string value "http://xx.xx.xx.xx:55939/ABCDevice?wsdl" which is determined only after run time.
How can i do so ?
I don't consider this as an Apache Maven specific issue, but a general Java issue (Maven probably made you aware of it).
During build-time you have no idea what the url should be. Depending on the type of application you have several options:
JNDI (in case of a webcontainer)
A properties file on a predefined location
System properties
As arguments (in case of executable jar)
Adjust web.xml before deploying (some webcontainers can help you with this)
...
In you use a framework like Spring there are easy ways to inject one the options above.
Related
I have a spring boot app that has tests for database stuff and I'm supporting mysql and mssql.
I have src/text/resources/application-mysql.properties and src/text/resources/application-mssql.properties
What environment variable can I set when I run my tests to tell Spring which test properties file to use?
Property files in the format application-*.properties are activated using Spring Profiles. Same thing for YAML files, by the way! It is important to know that application.properties is still loaded first and any profile-specific properties will overwrite previously loaded properties (kind of the whole point of Spring Profiles).
There are multiple ways to enable profiles:
To answer your question, you can set the SPRING_PROFILES_ACTIVE environment variable to enable profiles. For example, export SPRING_PROFILES_ACTIVE=mysql. You can also specify multiple profiles (and they are loaded in the same order) by separating them with a comma: export SPRING_PROFILES_ACTIVE=localdefaults,local.
You can also use the JVM parameter, spring.profiles.active. The value follows the same format as that of the environment variable. For example, -Dspring.profiles.active=mysql.
You can use the #ActiveProfiles annotation on your test class. For example:
// Other annotations...
#ActiveProfiles("mysql")
public class MyTest {
If you want to enable profiles during a build, you can set the spring.profiles.active property in Maven. For example:
<profiles>
<profile>
<id>mysql</id>
<properties>
<spring.profiles.active>mysql</spring.profiles.active>
</properties>
</profile>
...
</profiles>
Here's a weird one I recently learned. You can also set active profiles with the spring.profiles.active in a properties file. I imagine this has its uses, but have never used this approach.
Read more about everything I have covered:
https://docs.spring.io/spring-boot/docs/current/reference/html/howto.html#howto.properties-and-configuration
https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/test/context/ActiveProfiles.html
What does adding the '#' to name value of application.properties to the beginning and to the end mean?
I couldn't find usage of something like this. I checked the Spring docs as well, but I couldn't find it. Is this usage a generic thing for programming or specific to application.properties of Spring?
Please go through the documentation
Rather than hardcoding some properties that are also specified in your
project’s build configuration, you can automatically expand them by
instead using the existing build configuration. This is possible in
both Maven and Gradle.
The format you mentioned is for Maven
You can automatically expand properties from the Maven project by
using resource filtering. If you use the spring-boot-starter-parent,
you can then refer to your Maven ‘project properties’ with #..#
placeholders
Update
With Spring Boot Actuator dependency added to pom.xml
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
and
info endpoint exposed (for http : management.endpoints.web.exposure.include=info )
a quick verification of this can be done.
Add the following property to pom.xml
<properties>
<app.info.test>Test Value</app.info.test>
</properties>
and following entries in the application.properties file
info.app.name= Test App
info.app.java.source=1.8
info.app.test=#app.info.test#
Hitting http://localhost:8080/actuator/info will give the following response
{"app":{"name":"Test App","java":{"source":"1.8"},"test":"Test Value"}}
Straight Forward answer is the value which you store with #name# in application.properties are initialized when your project build start (based on same parameter name you pass with command).
It's used when you want to pass value of that variable at time of build
or value which are different based on environment.If you don't do that then it value becomes fixed.
when you're want to pass some parameter which are constant or repetitively use in your application like mail configuration or AWS configuration, version or etc. that things define in application.properties file.
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'm setting up a CI situation in which I will deploy my web app to a test environment. In this test environment, I want the business objects used by the app to be mocks of the real ones; the mocks will return static test data. I'm using this to run tests agains my ui. I'm controlling the injections of these business object dependencies with Spring; it's a struts 2 application, for what that's worth.
My question is Maven related, I think. What is the best way to have my Maven build determine whether or not to build the spring configuration out for injecting the mocks or injecting the real thing? Is this a good use for maven profiles? Other alternatives?
Spring itself has support for profiles (if you're using 3.1 or newer), for a web-application you can use context-parameter to set the active profile for different environments in the web.xml:
<context-param>
<param-name>spring.profiles.default</param-name>
<param-value>test</param-value>
</context-param>
Edit: For Maven & Jenkins, you should be able to set the parameter for a build job as follows:
First, let Maven filter your xml-resources (in this example, only files ending with xml are filtered, others are included without filtering) by adding the following into your pom.xml inside the <build> </build> -tags:
<resources>
<resource>
<directory>src/main/webapp</directory>
<filtering>true</filtering>
<includes>
<include>**/*xml</include>
</includes>
</resource>
<resource>
<directory>src/main/webapp</directory>
<filtering>false</filtering>
<excludes>
<exclude>**/*xml</exclude>
</excludes>
</resource>
</resources>
Then, parameterize the context-param in your web.xml:
<context-param>
<param-name>spring.profiles.default</param-name>
<param-value>${env.SPRINGPROFILE}</param-value>
</context-param>
Then parameterize the build job in Jenkins to set the desired string parameter for SPRINGPROFILE (for example test or prod): https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build
It's probably a bad idea to do anything with the build of the web app artifact ( Maven best practice for generating artifacts for multiple environments [prod, test, dev] with CI/Hudson support? ). While you could use various mechanisms to produce a WAR file with different configurations of the Spring injections for different contexts, the WAR artifact should be the same every time it's built.
In order to extract the configuration out of the WAR, I have used Spring 3's ability to pull in override values from an external property file. I define default, i.e. produciton, values of my business objects. And I configure spring to check for the existence of a properties file, something I will deploy when the app is in a testing environment and requires mock injections. If that properties file exists, it's values are injected instead. Here's the relevent bit of the spring config file.
<!-- These are the default values -->
<util:properties id="defaultBeanClasses">
<prop key="myManagerA">com.myco.ManagerAImpl</prop>
<prop key="myManagerB">com.myco.ManagerBImpl</prop>
</util:properties>
<!-- Pull in the mock overrides if they exist. -->
<context:property-placeholder
location="file:///my/location/mockBeans.properties"
ignore-resource-not-found="true"
properties-ref="defaultBeanClasses"/>
<!-- The beans themselves. -->
<bean id="managerA" class="${myManagerA}"/>
<bean id="managerB" class="${myManagerB}"/>
And here is the contents of the external "mockBeans.properties" file:
#Define mock implementations for core managers
myManagerA=com.myco.ManagerAMockImpl
myManagerB=com.myco.ManagerBMockImpl
This works nicely. You can even include the mockBeans.properties file in the actual WAR, if you like, but not in the live location. Then the test environment task would be too move it to the location pointed at by the spring config. Alternatively, you could have the mock properties reside in a completely different project.