Spring Boot + Logback - external config vs local config

I have a Spring Boot app with a local application.properties file, containing among others:

logging.config=src/main/resources/local/logback-dev.xml

In this logback-dev.xml file, there is a file appender with a local path (say /local/path/log/)

When deploying to a different environment (say PROD), the guy who deploy uses his own application.properties file as externalized configuration (--spring.config.location=...), containing among others:

logging.config=/prod/path/logback-prod.xml

In that logback-prod.xml file, there is a file appender with a different path (say /prod/path/log/)

When running the application, an error rises, as it seems both files are utilized: we get in the log present in /prod/path/log/ messages such as "cannot find path /local/path/log/"

Could someone explain what's happening here? I thought the externalized config would override the local one, but something is odd here.

edited Oct 3 '18 at 15:47

adarshr

49.1k20116151

asked Oct 3 '18 at 15:44

Khalil Bouzekri

256

Which version of Spring Boot is this? Generally there is a main application.properties which is used for prod and an application-dev.properties where values are overridden. We can switch to the -dev profile by specifying --spring.profiles.active=dev at command line.

– adarshr
Oct 3 '18 at 15:52

Spring Boot 2.0.3

– Khalil Bouzekri
Oct 3 '18 at 18:01

Actually we do not have the required values for the PROD env., thus it has to come from an externalized configuration file. Would it mean that we do not need the application.properties since it will be provided later on? Or else a rather "empty" application.properties file (without PROD specific data for example)? This issue actually came from a mistake, but it impacted the PROD env. and we do not exactly understand why, would be nice to know what happened

– Khalil Bouzekri
Oct 3 '18 at 18:09

1

Are you sure you haven’t somehow packaged your local application.properties along with the fat jar?

– adarshr
Oct 3 '18 at 18:11

yes it had been packaged actually, we thought it did not matter since it would be overriden anyway. Which works except for that logger...

– Khalil Bouzekri
Oct 3 '18 at 18:26

|
show 2 more comments

I have a Spring Boot app with a local application.properties file, containing among others:

logging.config=src/main/resources/local/logback-dev.xml

In this logback-dev.xml file, there is a file appender with a local path (say /local/path/log/)

logging.config=/prod/path/logback-prod.xml

In that logback-prod.xml file, there is a file appender with a different path (say /prod/path/log/)

When running the application, an error rises, as it seems both files are utilized: we get in the log present in /prod/path/log/ messages such as "cannot find path /local/path/log/"

Could someone explain what's happening here? I thought the externalized config would override the local one, but something is odd here.

edited Oct 3 '18 at 15:47

adarshr

49.1k20116151

asked Oct 3 '18 at 15:44

Khalil Bouzekri

256

Which version of Spring Boot is this? Generally there is a main application.properties which is used for prod and an application-dev.properties where values are overridden. We can switch to the -dev profile by specifying --spring.profiles.active=dev at command line.

– adarshr
Oct 3 '18 at 15:52

Spring Boot 2.0.3

– Khalil Bouzekri
Oct 3 '18 at 18:01

Actually we do not have the required values for the PROD env., thus it has to come from an externalized configuration file. Would it mean that we do not need the application.properties since it will be provided later on? Or else a rather "empty" application.properties file (without PROD specific data for example)? This issue actually came from a mistake, but it impacted the PROD env. and we do not exactly understand why, would be nice to know what happened

– Khalil Bouzekri
Oct 3 '18 at 18:09

1

Are you sure you haven’t somehow packaged your local application.properties along with the fat jar?

– adarshr
Oct 3 '18 at 18:11

yes it had been packaged actually, we thought it did not matter since it would be overriden anyway. Which works except for that logger...

– Khalil Bouzekri
Oct 3 '18 at 18:26

|
show 2 more comments

I have a Spring Boot app with a local application.properties file, containing among others:

logging.config=src/main/resources/local/logback-dev.xml

In this logback-dev.xml file, there is a file appender with a local path (say /local/path/log/)

logging.config=/prod/path/logback-prod.xml

In that logback-prod.xml file, there is a file appender with a different path (say /prod/path/log/)

When running the application, an error rises, as it seems both files are utilized: we get in the log present in /prod/path/log/ messages such as "cannot find path /local/path/log/"

Could someone explain what's happening here? I thought the externalized config would override the local one, but something is odd here.

edited Oct 3 '18 at 15:47

adarshr

49.1k20116151

asked Oct 3 '18 at 15:44

Khalil Bouzekri

256

I have a Spring Boot app with a local application.properties file, containing among others:

logging.config=src/main/resources/local/logback-dev.xml

In this logback-dev.xml file, there is a file appender with a local path (say /local/path/log/)

logging.config=/prod/path/logback-prod.xml

In that logback-prod.xml file, there is a file appender with a different path (say /prod/path/log/)

When running the application, an error rises, as it seems both files are utilized: we get in the log present in /prod/path/log/ messages such as "cannot find path /local/path/log/"

Could someone explain what's happening here? I thought the externalized config would override the local one, but something is odd here.

spring-boot logback properties-file

edited Oct 3 '18 at 15:47

adarshr

49.1k20116151

asked Oct 3 '18 at 15:44

Khalil Bouzekri

256

edited Oct 3 '18 at 15:47

adarshr

49.1k20116151

asked Oct 3 '18 at 15:44

Khalil Bouzekri

256

edited Oct 3 '18 at 15:47

adarshr

49.1k20116151

edited Oct 3 '18 at 15:47

adarshr

49.1k20116151

edited Oct 3 '18 at 15:47

adarshr

49.1k20116151

asked Oct 3 '18 at 15:44

Khalil Bouzekri

256

asked Oct 3 '18 at 15:44

Khalil Bouzekri

256

asked Oct 3 '18 at 15:44

Khalil Bouzekri

256

Which version of Spring Boot is this? Generally there is a main application.properties which is used for prod and an application-dev.properties where values are overridden. We can switch to the -dev profile by specifying --spring.profiles.active=dev at command line.

– adarshr
Oct 3 '18 at 15:52

Spring Boot 2.0.3

– Khalil Bouzekri
Oct 3 '18 at 18:01

Actually we do not have the required values for the PROD env., thus it has to come from an externalized configuration file. Would it mean that we do not need the application.properties since it will be provided later on? Or else a rather "empty" application.properties file (without PROD specific data for example)? This issue actually came from a mistake, but it impacted the PROD env. and we do not exactly understand why, would be nice to know what happened

– Khalil Bouzekri
Oct 3 '18 at 18:09

1

Are you sure you haven’t somehow packaged your local application.properties along with the fat jar?

– adarshr
Oct 3 '18 at 18:11

yes it had been packaged actually, we thought it did not matter since it would be overriden anyway. Which works except for that logger...

– Khalil Bouzekri
Oct 3 '18 at 18:26

|
show 2 more comments

Which version of Spring Boot is this? Generally there is a main application.properties which is used for prod and an application-dev.properties where values are overridden. We can switch to the -dev profile by specifying --spring.profiles.active=dev at command line.

– adarshr
Oct 3 '18 at 15:52

Spring Boot 2.0.3

– Khalil Bouzekri
Oct 3 '18 at 18:01

Actually we do not have the required values for the PROD env., thus it has to come from an externalized configuration file. Would it mean that we do not need the application.properties since it will be provided later on? Or else a rather "empty" application.properties file (without PROD specific data for example)? This issue actually came from a mistake, but it impacted the PROD env. and we do not exactly understand why, would be nice to know what happened

– Khalil Bouzekri
Oct 3 '18 at 18:09

1

Are you sure you haven’t somehow packaged your local application.properties along with the fat jar?

– adarshr
Oct 3 '18 at 18:11

yes it had been packaged actually, we thought it did not matter since it would be overriden anyway. Which works except for that logger...

– Khalil Bouzekri
Oct 3 '18 at 18:26

Which version of Spring Boot is this? Generally there is a main application.properties which is used for prod and an application-dev.properties where values are overridden. We can switch to the -dev profile by specifying --spring.profiles.active=dev at command line.

– adarshr
Oct 3 '18 at 15:52

Spring Boot 2.0.3

– Khalil Bouzekri
Oct 3 '18 at 18:01

Actually we do not have the required values for the PROD env., thus it has to come from an externalized configuration file. Would it mean that we do not need the application.properties since it will be provided later on? Or else a rather "empty" application.properties file (without PROD specific data for example)? This issue actually came from a mistake, but it impacted the PROD env. and we do not exactly understand why, would be nice to know what happened

– Khalil Bouzekri
Oct 3 '18 at 18:09

Are you sure you haven’t somehow packaged your local application.properties along with the fat jar?

– adarshr
Oct 3 '18 at 18:11

yes it had been packaged actually, we thought it did not matter since it would be overriden anyway. Which works except for that logger...

– Khalil Bouzekri
Oct 3 '18 at 18:26

|
show 2 more comments

1 Answer
1

active

oldest

votes

We have the same problem and have found a solution with the help of this documentation:
External Configuration
https://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#boot-features-external-config
Application Properties
https://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#boot-features-external-config-application-property-files

In Pom we added:

<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-jar-plugin</artifactId>
 <configuration>
 <excludes>
 <exclude>**/application.properties</exclude>
 <exclude>**/application-development.properties</exclude>
 <exclude>**/application-production.properties</exclude>
 <exclude>**/logback.xml</exclude>
 </excludes>
 </configuration>
 </plugin>

Hope this will solve your problem and helping to understand.

answered Nov 15 '18 at 10:14

Devilluminati

Thanks for your proposition. However it seems that this would only work if there is always an externalized configuration. In my case it might not be the case (sometimes the local one should be used, but in the case of an externalized one, that one should be taken into account), as unfortunately we do not have a say on the deployment.

– Khalil Bouzekri
Nov 20 '18 at 9:42

add a comment |

Your Answer

StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52630945%2fspring-boot-logback-external-config-vs-local-config%23new-answer', 'question_page');

);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

In Pom we added:

<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-jar-plugin</artifactId>
 <configuration>
 <excludes>
 <exclude>**/application.properties</exclude>
 <exclude>**/application-development.properties</exclude>
 <exclude>**/application-production.properties</exclude>
 <exclude>**/logback.xml</exclude>
 </excludes>
 </configuration>
 </plugin>

Hope this will solve your problem and helping to understand.

answered Nov 15 '18 at 10:14

Devilluminati

Thanks for your proposition. However it seems that this would only work if there is always an externalized configuration. In my case it might not be the case (sometimes the local one should be used, but in the case of an externalized one, that one should be taken into account), as unfortunately we do not have a say on the deployment.

– Khalil Bouzekri
Nov 20 '18 at 9:42

add a comment |

In Pom we added:

<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-jar-plugin</artifactId>
 <configuration>
 <excludes>
 <exclude>**/application.properties</exclude>
 <exclude>**/application-development.properties</exclude>
 <exclude>**/application-production.properties</exclude>
 <exclude>**/logback.xml</exclude>
 </excludes>
 </configuration>
 </plugin>

Hope this will solve your problem and helping to understand.

answered Nov 15 '18 at 10:14

Devilluminati

Thanks for your proposition. However it seems that this would only work if there is always an externalized configuration. In my case it might not be the case (sometimes the local one should be used, but in the case of an externalized one, that one should be taken into account), as unfortunately we do not have a say on the deployment.

– Khalil Bouzekri
Nov 20 '18 at 9:42

add a comment |

In Pom we added:

<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-jar-plugin</artifactId>
 <configuration>
 <excludes>
 <exclude>**/application.properties</exclude>
 <exclude>**/application-development.properties</exclude>
 <exclude>**/application-production.properties</exclude>
 <exclude>**/logback.xml</exclude>
 </excludes>
 </configuration>
 </plugin>

Hope this will solve your problem and helping to understand.

answered Nov 15 '18 at 10:14

Devilluminati

In Pom we added:

<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-jar-plugin</artifactId>
 <configuration>
 <excludes>
 <exclude>**/application.properties</exclude>
 <exclude>**/application-development.properties</exclude>
 <exclude>**/application-production.properties</exclude>
 <exclude>**/logback.xml</exclude>
 </excludes>
 </configuration>
 </plugin>

Hope this will solve your problem and helping to understand.

answered Nov 15 '18 at 10:14

Devilluminati

answered Nov 15 '18 at 10:14

Devilluminati

answered Nov 15 '18 at 10:14

Devilluminati

answered Nov 15 '18 at 10:14

Devilluminati

Thanks for your proposition. However it seems that this would only work if there is always an externalized configuration. In my case it might not be the case (sometimes the local one should be used, but in the case of an externalized one, that one should be taken into account), as unfortunately we do not have a say on the deployment.

– Khalil Bouzekri
Nov 20 '18 at 9:42

add a comment |

Thanks for your proposition. However it seems that this would only work if there is always an externalized configuration. In my case it might not be the case (sometimes the local one should be used, but in the case of an externalized one, that one should be taken into account), as unfortunately we do not have a say on the deployment.

– Khalil Bouzekri
Nov 20 '18 at 9:42

Thanks for your proposition. However it seems that this would only work if there is always an externalized configuration. In my case it might not be the case (sometimes the local one should be used, but in the case of an externalized one, that one should be taken into account), as unfortunately we do not have a say on the deployment.

– Khalil Bouzekri
Nov 20 '18 at 9:42

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Odtnhj