Override Server Port while execution

$ java -jar -Dserver.port=8082 event-service.jar

How spring cloud config use local property override remote property

spring:
  profiles: default
  cloud:
    config:
      allowOverride: true
      overrideNone: true
      server:
        bootstrap: true
        git:
          uri: file://${user.home}/config


 both should reside on config server side, and if I understand correctly, spring.cloud.config.allow-override=true allows system properties from client side to override config server values right?

The problem I'm facing now is I'm trying to have a local prop on config client side to override the same prop from config server, let's say

config server:

key=valueA
In which file (like bootstrap.properties, application.properties or else) should I put on client side

key=valueB
so that client will use valueB for this key? Yes

--------------------
define following properties in git repo (as a source for config-server) [for given profile]:
  spring.cloud.config:
    overrideSystemProperties: false
    overrideNone: true

keep in mind properties (especially overrideSystemProperties & overrideNone) in bootsrap.yml are overriden by those from config-server by default

spring:
  cloud:
    config:
      allowOverride: true
      overrideNone: true
      overrideSystemProperties: false

Application.yml - bootstrap.yml - prioroty

bootstrap.yml is loaded before application.yml.

It is typically used for the following:

when using Spring Cloud Config Server, you should specify spring.application.name and
spring.cloud.config.server.git.uri inside bootstrap.yml
some encryption/decryption information
Technically, bootstrap.yml is loaded by a parent Spring ApplicationContext. That parent ApplicationContext is loaded before the one that uses application.yml.

-------------------------------------------------------------------
bootstrap.yml or bootstrap.properties

It's only used/needed if you're using Spring Cloud and your application's configuration is stored on a remote configuration server (e.g. Spring Cloud Config Server).

Note that the bootstrap.yml or bootstrap.properties can contain additional configuration (e.g. defaults) but generally you only need to put bootstrap config here.

Typically it contains two properties:

location of the configuration server (spring.cloud.config.uri)
name of the application (spring.application.name)
Upon startup, Spring Cloud makes an HTTP call to the config server with the name of the application and retrieves back that application's configuration.


application.yml or application.properties

Contains standard application configuration - typically default configuration since any configuration retrieved during the bootstrap process will override configuration defined here.


---------------------------------------------------------------------
same content placed in both files then

appliaction yaml file have the higher priority and ovveride the content of the bootstrap property

info endpoint - application.yml

info:
  build:
    artifact: '@project.artifactId@'
    name: '@project.name@'
    description: '@project.description@'
    version: '@project.version@'

Note:  value should not start with any token like @

pom.xml:
 (build)
        (resources)
            (resource)
                (directory)src/main/resources(/directory)
                (filtering)true(/filtering)
            (/resource)
        (/resources)
        (plugins)
            (plugin)

Cannot get maven project.version property in a Spring application with @Value

After some research and trials on how to get the maven project version in a Spring Boot application I couldn't find anything working for me.

Using a manifest is definitively a rotten path due to class loaders issues, i.e. one gets the first manifest Spring finds, which in my case was not the one of my application.

One solution I have found is to use the maven resources plugin to "filter" (replace) properties in resource files. In this case the Spring application.properties.

Below are the steps to make this work.

In the pom, activate resources filtering with the following definition:

    (resources)
        (resource)
            (filtering)true(/filtering)
            (directory)src/main/resources(/directory)
            (includes)
                (include)application.properties(/include)
            (/includes)
        (/resource)
    (/resources)
In the application.properties file:

  application.name=@project.artifactId@
  build.version=@project.version@
  build.timestamp=@timestamp@
Notice the @property@ instead of ${property}. in the application.properties file.

The spring-boot-starter-parent pom redefines the standard ${} delimiter as @:

    (resource.delimiter)@(/resource.delimiter) (!-- delimiter that doesn't clash with Spring ${} placeholders --)
    (delimiters)
        (delimiter)${resource.delimiter}(/delimiter)
    (/delimiters)
One can then access those properties in Spring using @Value like this:

@Value("${application.name}")
private String applicationName;

@Value("${build.version}")
private String buildVersion;

@Value("${build.timestamp}")
private String buildTimestamp;

How can I specify the default JVM arguments for programs I run from eclipse?

Yes, right click the project. Click Run as then Run Configurations. You can change the parameters passed to the JVM in the Arguments tab in the VM Arguments box.

That configuration can then be used as the default when running the project.


Go to Window → Preferences → Java → Installed JREs. Select the JRE you're using, click Edit, and there will be a line for Default VM Arguments which will apply to every execution. For instance, I use this on OS X to hide the icon from the dock, increase max memory and turn on assertions:

-Xmx512m -ea -Djava.awt.headless=true


Go to Window → Preferences → Java → Installed JREs. Select the JRE you're using, click Edit, and there will be a line for Default VM Arguments which will apply to every execution. For instance, I use this on OS X to hide the icon from the dock, increase max memory and turn on assertions:

-Xmx512m -ea -Djava.awt.headless=true

difference between EnableEurekaClient and EnableDiscoveryClient

There are multiple implementations of "Discovery Service" (eureka, consul, zookeeper).

@EnableDiscoveryClient lives in spring-cloud-commons and picks the implementation on the classpath.  GENERIC

@EnableEurekaClient lives in spring-cloud-netflix and only works for eureka. If eureka is on your classpath, they are effectively the same. SPECIFIC

service-discovery-eureka-cloud-foundry

Eureka server

It is really easy to use Eureka with Spring Boot. The first thing you need to start is obviously the server:

1. Go to https://start.spring.io/, add Eureka Server to the list of dependencies and generate the project.  
   
2. Import the project in your IDE
3. Open EurekaApplication.java and add @EnableEurekaServer. It should look like this:
   1 2 3 4 5 6 7 8

   @SpringBootApplication @EnableEurekaServer public class EurekaApplication {     public static void main(String[] args) {         SpringApplication.run(EurekaApplication.class, args);     } }

4. Add the following lines to application.yml to configure the server: (I prefer YAML, but it is also possible to use application.properties which is provided by the project from the Spring Initializer)
   1 2 3 4 5 6 7 8 9 10

   server:   port: 8761 spring:   application:     name: eureka eureka:   client:     registerWithEureka: false     fetchRegistry: false

   
   The properties registerWithEureka: false and fetchRegistry: false prevent that the application acts as a Eureka client and server at the same time.

Eureka client

The next step is to create an application that registers with the service registry. Go to https://start.spring.io/ and create another application. This time add Eureka Discovery as a dependency:

After importing the project in your IDE, add @EnableEurekaClient in the Main class:

1 2 3 4 5 6 7 8

@SpringBootApplication @EnableEurekaClient public class TestAppApplication {     public static void main(String[] args) {         SpringApplication.run(TestAppApplication.class, args);     } }

In application.yml only the application name and the default zone need to be set. The name will be used to register and the defaultZone is the URL of the Eureka server. For a local setup this will be http://127.0.0.1:8761/eureka/.

1 2 3 4 5 6 7

spring:   application:     name: testApp eureka:   client:     serviceUrl:       defaultZone: http://127.0.0.1:8761/eureka/

If you start both applications, the logs show that the testApp registers its instance:

Log output of testApp:

1 2	DiscoveryClient_TESTAPP/172.16.177.147:testApp: registering service... DiscoveryClient_TESTAPP/172.16.177.147:testApp - registration status: 204

Log output of Eureka :

1	Registered instance TESTAPP/172.16.177.147:testApp with status UP

Eureka comes with a built-in web UI where it shows all registered services. Go to http://127.0.0.1:8761 to see the registered instance of testApp:

Now that the local setup is running, let’s take it to the cloud!

Cloud setup

The simplest way to deploy an application to Cloud Foundry is to upload the Jar file directly in Cloud Foundry’s web frontend. But this has some disadvantages. The configuration must be done manually and probably the biggest disadvantage: It is not automated!

To allow automated deployments a manifest file is needed (https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html). If you take a closer look at the manifest.yml of the Eureka server, you see the most relevant property host. This defines that the service will be reachable under eureka-test-service.cfapps.io.

1 2 3 4 5 6

--- applications: - name: eureka   memory: 512MB   host: eureka-test-service   path: target/eureka-0.0.1-SNAPSHOT.jar

To deploy the server to Cloud Foundry we will use the Cloud Foundry CLI. If you have not set up the CLI, you can look it up here: http://docs.cloudfoundry.org/cf-cli/

1. First build the jar: mvn clean install
2. Then push it to Cloud Foundry: cf push

Congratulations, you have deployed your Eureka server to Cloud Foundry! To verify this, go to http://eureka-test-service.cfapps.io and have a look at the web UI of Eureka.

Adding clients

A service registry without clients is pointless. Therefore the next step is to configure our testApp to use Eureka in the cloud. The easiest way would be to set the default zone to http://eureka-test-service.cfapps.io/eureka/, but this would bind the application to this single instance. If the URL changes you have to recompile the application. Instead of storing environment specific configuration in the application, the environment should provide the URL (see http://12factor.net/config). An easy way to provide the URL via an environment variable is a user provided service.

User provided service

A user provided service (https://docs.cloudfoundry.org/devguide/services/user-provided.html) with the name eureka and the URL of the service registry can be created with the following command:

1	cf cups eureka -p '{"url": "http://eureka-test-service.cfapps.io/eureka/"}'

To enable an application to use a service in Cloud Foundry you have to bind the service to the application.

Cloud profile

If the service is bound to our application it will provide the Eureka URL in the environment variable vcap.services.eureka.credentials.url. To use this in the testApp add a cloud specific spring profile to application.yml and set the defaultZone:

9 10 11 12 13 14 15 16 17 18

---   spring:   profiles: cloud eureka:   instance:     nonSecurePort: 80     hostname: ${vcap.application.uris[0]}   client:     service-url:       defaultZone: ${vcap.services.eureka.credentials.url}

The hostname is set to vcap.application.uris[0]. This variable is provided by Cloud Foundry and contains the public URL of an application. This URL will be used to register with Eureka. Other services can then retrieve this URL from Eureka to connect to testApp.

Manifest

Just as the server project has a manifest.yml, so the testApp will have one:

• The active spring profile is selected with the environment variable spring.profiles.active: cloud which can be set in the env attribute.
• The service eureka is bound to this application in the services block.

The complete manifest.yml should look like this:

1 2 3 4 5 6 7 8 9 10

--- applications: - name: testApp   memory: 512MB   host: testApp-service   path: target/testApp-0.0.1-SNAPSHOT.jar   env:     spring.profiles.active: cloud   services:   - eureka

Deploy it to Cloud Foundry

1. As usual first build the jar: mvn clean install
2. Now push it to Cloud Foundry via CLI: cf push

The logs show the registration of the Eureka client with the Eureka server.

1 2	DiscoveryClient_TESTAPP/6b42392c-a1a5-473d-7513-8ff9e53cfc41: registering service... DiscoveryClient_TESTAPP/6b42392c-a1a5-473d-7513-8ff9e53cfc41 - registration status: 204

On the UI http://eureka-test-service.cfapps.io you can see that TESTAPP is registered.

That’s it! Within a few simple steps you have created a service registry with Spring Boot. First a Eureka server and client for a local setup, then configured both to be cloud ready and deployed them to Cloud Foundry.