spring-boot-thin-launcher
spring-boot-thin-launcher copied to clipboard
spring-projects-experimental
Ability to add additional external classpath directory
spring-boot-thin-launch works great for my none spring app as well but I lose the ability the setup external classpath.
Possible to add -Dthin.extraClassPath=xxxx ?
This option allows me to configure my logback.xml location
Can you explain a bit more with a sample app and a README? Why would you want to use the classpath to set an XML file location (you could just use a file URL)?
application with logback automatically searches for logback.xml configuration in its classpath. and I need to use external file. this way I can control the location of the log output
dont think there is a way to configure the location of logback.xml for none-spring boot app
Will update my demo project to show you
dont think there is a way to configure the location of logback.xml for none-spring boot app
Link to docs: https://logback.qos.ch/manual/configuration.html#configFileProperty
-Dlogback.configurationFile works (big thanks, not sure why i missed that :( )
however, i believe there may be other scenarios that I may need this feature. I believe fat spring-boot users also running into this scenario where user have to set layout=ZIP which overrides thin boot layout
Maybe. Not sure I understand those scenarios yet. Nothing to do yet, I guess.
Our use case for this functionality is that our application supports the concept of plugins which are represented by JAR files. The plugins that a particular instance of the application needs to use can't be determined at build time and is only determined at runtime by loading the plugin jars from known locations on the classpath.
@jcharris that’s a perfect use case for the existing thin.properties features. You just need to make all the “plugin” jars available in a Maven repository (local or remote).
If I can include just a directory path in thin.properties that would work fine. Having to edit the thin.properties file to include each plugin JAR and plugin JAR dependencies is not an application run time solution. With traditional WARs we have the build time dependencies in the WAR but can add additional functionality via JARs on the external classpath. This doesn't require any knowledge of exactly what is present in that directory until the application starts and looks for stuff that implements its Plugin interfaces..
Why would the runtime jars need to be in a specific directory though? You can just put them in a Maven repo layout and it will already work just fine.
Why would the runtime jars need to be in a specific directory though? You can just put them in a Maven repo layout and it will already work just fine.
some local deps are not in maven repo. (eg. build.gradle: implementation files("./lib/arcsoft-sdk-face-2.1.0.0.jar"))
Why would the runtime jars need to be in a specific directory though? You can just put them in a Maven repo layout and it will already work just fine.
application was released,but integration jars are unknown before release.,so we want add those jars in a specific directory,and load it at jvm start.
So can't you put them in ~/.m2/repository? You can use mvn install -D... I think, if you don't want to guess the layout.
So can't you put them in
~/.m2/repository? You can usemvn install -D...I think, if you don't want to guess the layout.
if thin-launcher support it , we only need to put jars into the directory. but if in your way,we have to : 1.install maven on server. 2.mvn install jars one by one 3.edit thin.properties
this is not convenient, and perhaps application manager doesn't have knowledge of "maven" and "thin-layout".
this is not convenient
I get that, but if we add an "additional classpath" option it makes the executions non-reproducible - you have to ensure that the classpath is valid before you run, and that means copying files around, which is unreliable and also not convenient. Who is the "application manager" in your scenario? What does he or she have to do to locate the additional libraries?
We may have an another possible use case. Users may be able to mount jar files in a k8s environment to enable/disable certain features with autoconfiguration.
