Mechanism to extend console command for Quarkus dev running

[hieunc278]

Description

Current, when run Quarkus application with Quarkus:dev profile, we saw several built-in console command like below.

The following commands are currently available: == Completed Application

[ ] - Restarts the application [e] - Edits the command line parameters and restarts ()

== Continuous Testing

[r] - Resume testing [o] - Toggle test output (disabled)

== HTTP

[w] - Open the application in a browser [d] - Open the Dev UI in a browser

== System

[s] - Force restart [i] - Toggle instrumentation based reload (disabled) [l] - Toggle live reload (enabled) [j] - Toggle log levels (INFO) [h] - Shows this help [q] - Quits the application

So, it could be good if Quarkus could provide the mechanism that allow application add more console command based on application's demand.

The following commands are currently available: == Completed Application

[ ] - Restarts the application [e] - Edits the command line parameters and restarts ()

== Continuous Testing

[r] - Resume testing [o] - Toggle test output (disabled)

== HTTP

[w] - Open the application in a browser [d] - Open the Dev UI in a browser

== System

[s] - Force restart [i] - Toggle instrumentation based reload (disabled) [l] - Toggle live reload (enabled) [j] - Toggle log levels (INFO) [h] - Shows this help [q] - Quits the application

== Custom App [k] custom console command

Configuration suggestion

No response

Additional context

As I tried to add this below source as on main thread : ConsoleStateManager.ConsoleContext consoleContext = ConsoleStateManager.INSTANCE.createContext("New");

I saw that it create another instance ( INSTANCE ) of ConsoleStateManager object, so I could not add to current as well as built-in console commands.

[stuartwdouglas]

What use cases do you have in mind?

You could do this by writing an extension, if I added support for this into the application itself then the utilities commands would end up in the final application.

[hieunc278]

Dear @stuartwdouglas,

Thanks for your feedback.

This suggestion come when I need to add some continuous command line to test such as login step, then call register command to wait response from Grpc server as server side streaming.

And as I saw, Quarkus dev running is great interactive as well. So I would like to add some my console command to add to exists built-in console command like restart, quit, help .....

In conclusion, my idea is app side could some how write CustomConsoleHandler, then plug into exists ConsoleStateManager.

Could you share more detail about writing an extension ?

[hieunc278]

Dear @stuartwdouglas,

I just wonder about another point, could you please review it also ?

In ConsoleStateManager class, we have the instance variable as below :

public static final ConsoleStateManager INSTANCE = new ConsoleStateManager();

However, when I tried to access that variable with below line :

ConsoleStateManager.ConsoleContext consoleContext = ConsoleStateManager.INSTANCE.createContext("NewCtx");

New instance of ConsoleStateManager is created, even I access via static final INSTANCE variable. So my new console command is not merged with Built-in console command as well.

ConsoleStateManager default constructor current thread id : 71, thread name : build-53 ConsoleStateManager default constructor current thread id : 96, thread name : Quarkus Main Thread

Then, it seems that INSTANCE is not shared between threads, is it correct ?

As I checked, it seems that due to different class loader, so two instances of ConsoleStateManager were created. Is it right ?

[hieunc278]

Dear @cescoffier, Could you please review it also ?

[mkouba]

Could you share more detail about writing an extension ?

I'm not sure what Stuart had in mind but you can start with the docs: https://quarkus.io/guides/#writing-extensions

In conclusion, my idea is app side could some how write CustomConsoleHandler, then plug into exists ConsoleStateManager.

I'm not so sure it's a good idea to "pollute" the application with dev mode stuff. Do you try to automate some initialization logic in the dev mode? If so then you can try to combine "startup" beans enabled for the dev mode. You can even inject the io.quarkus.runtime.LaunchMode to detect that the app is run in the dev mode.