Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document the need to use the launcher to be able to use application.* properties in a custom banner #22519

Closed
orenw1 opened this issue Jul 22, 2020 · 7 comments
Labels
status: superseded An issue that has been superseded by another

Comments

@orenw1
Copy link

orenw1 commented Jul 22, 2020

Some of the banner properties not populated when running with unpacked jar and custom banner

When running Spring Boot application with custom banner and unpacked jar as documented in [1],
the following banner properties that described in [2] are not printed

  • application.version
  • application.formatted-version
  • application.title

[1] Deploying to Containers

[2] Customizing the Banner

Spring Boot version: 2.3.1.RELEASE

i saw this #21705 that looks similar issue, but i tried with 2.3.1.RELEASE version and it still does not show the values.

Example project that re-create the issue

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jul 22, 2020
@wilkinsona wilkinsona self-assigned this Jul 23, 2020
@wilkinsona
Copy link
Member

Thanks for the sample. The problem is as @philwebb described here. The change made in #21705 has not helped in your case as you are not using Spring Boot's launcher. This means that it doesn't get a chance to make it possible to load a manifest (which is the source of the application version) from a folder.

You can avoid the problem by unpacking the jar and then using JarLauncher to start the app:

$ java -cp . org.springframework.boot.loader.JarLauncher
DEMO BANNER START

application version           = 0.0.1-SNAPSHOT
application formatted version =  (v0.0.1-SNAPSHOT)
spring-boot version           = 2.3.1.RELEASE
spring-boot formatted version =  (v2.3.1.RELEASE)
application title             = demo-banner

DEMO BANNER END
2020-07-23 09:41:21.631  INFO 2004 --- [           main] c.e.demobanner.DemoBannerApplication     : Starting DemoBannerApplication v0.0.1-SNAPSHOT on fulcrum.local with PID 2004 (/Users/awilkinson/dev/temp/demo-banner/target/unpacked/BOOT-INF/classes started by awilkinson in /Users/awilkinson/dev/temp/demo-banner/target/unpacked)
2020-07-23 09:41:21.633  INFO 2004 --- [           main] c.e.demobanner.DemoBannerApplication     : No active profile set, falling back to default profiles: default
2020-07-23 09:41:21.992  INFO 2004 --- [           main] c.e.demobanner.DemoBannerApplication     : Started DemoBannerApplication in 0.598 seconds (JVM running for 0.866)
=== demo banner application ===

I don't think there's anything we can do to improve this behaviour. When launched with a classpath of BOOT-INF/classes and BOOT-INF/lib/*.jar the manifest isn't even on the classpath so there's no reliable way for us to find it.

Let's update the banner customization documentation to note the restriction and recommend the use of the launcher with an exploded archive.

@wilkinsona wilkinsona changed the title Some of the banner properties not populated when running with unpacked jar and custom banner Document the need to use the launcher to be able to use application.* properties in a custom banner Jul 23, 2020
@wilkinsona wilkinsona changed the title Document the need to use the launcher to be able to use application.* properties in a custom banner Document the need to use the launcher to be able to use application.* properties in a custom banner Jul 23, 2020
@wilkinsona
Copy link
Member

Another option is to set the application.version and application.title properties in application.properties. You can use placeholders to get the values from the Maven project:

application.version=@project.version@
application.title=@project.name@

@wilkinsona wilkinsona added type: documentation A documentation update and removed status: waiting-for-triage An issue we've not yet triaged labels Jul 23, 2020
@wilkinsona wilkinsona added this to the 2.3.x milestone Jul 23, 2020
@orenw1
Copy link
Author

orenw1 commented Jul 23, 2020

@wilkinsona, thank you for the answer and suggestion!

@wilkinsona wilkinsona removed their assignment Jan 12, 2021
@robert-smith-911
Copy link
Contributor

@wilkinsona I know this is an oldie, but mind if I update the docs for this one?

@philwebb
Copy link
Member

Closing in favor of PR #24982. Thanks @robert-smith-911!

@philwebb philwebb removed this from the 2.3.x milestone Jan 28, 2021
@philwebb philwebb added status: superseded An issue that has been superseded by another and removed type: documentation A documentation update labels Jan 28, 2021
@wilkinsona
Copy link
Member

Sorry for missing your question about updating the docs, @robert-smith-911. Thanks for opening a PR despite my lack of response.

@robert-smith-911
Copy link
Contributor

@wilkinsona You're welcome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: superseded An issue that has been superseded by another
Projects
None yet
Development

No branches or pull requests

5 participants