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

Configure or disable behavior wrt. command-line arguments? #508

Open
buergerj opened this issue Aug 18, 2022 · 4 comments
Open

Configure or disable behavior wrt. command-line arguments? #508

buergerj opened this issue Aug 18, 2022 · 4 comments

Comments

@buergerj
Copy link

In my project, I use https://github.com/fonimus/ssh-shell-spring-boot . This has recently been upgraded to use version 2.1.0 of Spring Shell.

My application makes use of command-line arguments. Now, I observe that Spring Shell tries to interpret the command-line argument as a shell command and execute it. This results in an error on application start since no matching command is registered, obviously:

No command found for '--configFile=/home/people/.../file'
org.springframework.shell.CommandNotFound: No command found for '--configFile=/home/people/.../file'
	at org.springframework.shell.Shell.evaluate(Shell.java:231)
	at com.github.fonimus.ssh.shell.ExtendedShell.evaluate(ExtendedShell.java:120)
	at com.github.fonimus.ssh.shell.ExtendedShell.run(ExtendedShell.java:110)
	at com.github.fonimus.ssh.shell.ExtendedShell.run(ExtendedShell.java:83)
	at org.springframework.shell.jline.NonInteractiveShellRunner.run(NonInteractiveShellRunner.java:104)
	at org.springframework.shell.DefaultShellApplicationRunner.run(DefaultShellApplicationRunner.java:65)
	at org.springframework.boot.SpringApplication.callRunner(SpringApplication.java:762)
	at org.springframework.boot.SpringApplication.callRunners(SpringApplication.java:752)
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:315)
	at de.k... myProject.main(Main.java:46)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.springframework.boot.devtools.restart.RestartLauncher.run(RestartLauncher.java:49)

I checked the documentation but could not find an answer to my question: (How) can I adapt this command-line argument parsing or maybe completely disable it?

@Eliak
Copy link

Eliak commented Aug 18, 2022

The same in my project too. With spring boot configuration additional location argument: --spring.config.additional-location=file:./../config/application.properties

@jvalkeal
Copy link
Contributor

This is a side effect that we now support commands without entering interactive shell. You could use any other boot style to define it's options like ENV variables.

I'm just thinking what should we do about this if we'd somehow allow user to pass properties to a shell app? It's a common way to pass properties to boot app via command-line arguments but how to differentiate arguments for boot app itself vs. shell app.

@theborakompanioni
Copy link

This is a side effect that we now support commands without entering interactive shell. You could use any other boot style to define it's options like ENV variables.

I'm just thinking what should we do about this if we'd somehow allow user to pass properties to a shell app? It's a common way to pass properties to boot app via command-line arguments but how to differentiate arguments for boot app itself vs. shell app.

Ran into this today. For me, same exception as above when passing --spring.profiles.active=development, which feels to be a "valid"-ish use case for a shell application. Workaround via env variable SPRING_PROFILES_ACTIVE works fine. 🙌

@ullenboom
Copy link

Pls. fix this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants