Add very basic support for command line only applications

[geoand]

Relates to: #284

This is probably wrong on a few counts since it touches core things that I'm not entirely familiar with.
I'm opening this however with the hope to get some feedback on the approach.

The basic thing the user would use is the CommandLineRunner, similar to what Spring Boot has.

I also plan on looking into integrating Aesh as mentioned by @stalep

Supersedes #1238

[geoand]

@stalep I have a first working example using Æsh here: https://github.com/geoand/quarkus/tree/clrunner%2Baesh (uses Æsh 2.0.0 built locally)

[dmlloyd]

With some discussion it was agreed that having CDI supply the main method arguments is a possible approach. What is left is a way to gracefully exit the application; this PR uses the approach of adding a new bytecode recorder when the extension is present to call a main method and exit.

Some alternative possibilities:

• A config property that triggers immediate exit
• Some annotation that can go on to a method which accepts a String[] and returns an int (so the user can return an exit code)
• An alternative non-blocking variation on System.exit(int)

[dmlloyd]

We don't want to use an entire separate bytecode recorder just for this one case.

[geoand]

👍

[geoand]

I just remembered another reason why I needed this recorder - besides needing to have a way to exit. Basically the command line entry points need to be run after everything else (I am thinking basically of CDI/Arc events here).
I didn't see a way to order the execution of templates (which basically would boil down to controlling the order that calls to the templates are written to in the generated class file) - did I miss something perhaps?

[geoand]

Also, in the command line application case, it doesn't make much sense I think to show the startup time after the actual work that is intended has been performed.

So in my view the AFTER_STARTUP execution time makes sense for such applications. Is there a large performance penalty at build time of having another bytecode recorder?

[dmlloyd]

It's not a large penalty by itself, but we don't want to introduce a cost if we don't need to. Since there can only ever be one of these (logically), it probably doesn't even need to be a bytecode recorder. You could for example produce a build item that contains the method info (maybe just the descriptor) to call, and then just emit a call to that method at the right spot if the build item is present.

[geoand]

Got it! I will look into it, thanks!

[geoand]

I'll give this a go to ensure that it can be implemented without too much trouble but I think there is another problem that will arise if we don't have the extra bytecode recorder.
Since we won't be able to capture arguments, we won't be able to support use cases like Aesh, were the user can write multiple commands and it would be our job to feed Aesh with the class names.

So in a non Aesh use case, yes there can only be one entry point (that makes absolute sense since it would be the equivalent of a main method) and no bytecode recorder is needed, but if we want to bring Aesh into the mix, not having one will probably be a problem.
WDYT?

[geoand]

I pushed a commit that removes the need for a new BytecodeRecorder. But it does mean that now some bytecode needs to be "written" by the extension :)

[geoand]

I believe that following a similar approach (where the extension actually participates in the creation of the bytecode) we could support Aesh as well

[geoand]

With some discussion it was agreed that having CDI supply the main method arguments is a possible approach. What is left is a way to gracefully exit the application; this PR uses the approach of adding a new bytecode recorder when the extension is present to call a main method and exit.

Some alternative possibilities:

• A config property that triggers immediate exit
• Some annotation that can go on to a method which accepts a String[] and returns an int (so the user can return an exit code)
• An alternative non-blocking variation on System.exit(int)

For CDI injection of the main args, I guess changes would need to be made to Arc?

Of the alternatives proposed for the exit strategy, I personally feel that the dedicated annotation is more natural. In that case could the rest of the infra put in place here be used? I mean that the generated bytecode would invoke the CLI method and then attempt to shutdown in a similar manner as is done here?

[geoand]

With some discussion it was agreed that having CDI supply the main method arguments is a possible approach. What is left is a way to gracefully exit the application; this PR uses the approach of adding a new bytecode recorder when the extension is present to call a main method and exit.
Some alternative possibilities:

• A config property that triggers immediate exit
• Some annotation that can go on to a method which accepts a String[] and returns an int (so the user can return an exit code)
• An alternative non-blocking variation on System.exit(int)

For CDI injection of the main args, I guess changes would need to be made to Arc?

Of the alternatives proposed for the exit strategy, I personally feel that the dedicated annotation is more natural. In that case could the rest of the infra put in place here be used? I mean that the generated bytecode would invoke the CLI method and then attempt to shutdown in a similar manner as is done here?

Also if the only way to inject args is via Arc, then I don't we will be able to incorporate Æsh

[dmlloyd]

For CDI injection of the main args, I guess changes would need to be made to Arc?

I don't think so (I'm not 100% sure though). The main class would have to expose the args somehow. But it's possible that the main method build step runs too late to produce a CDI bean build item.

Of the alternatives proposed for the exit strategy, I personally feel that the dedicated annotation is more natural. In that case could the rest of the infra put in place here be used? I mean that the generated bytecode would invoke the CLI method and then attempt to shutdown in a similar manner as is done here?

I'm not so sure. We want the user to be able to set the exit status. That's easy from an API perspective but it's difficult from the perspective that the user might be running this in dev mode, where calling System.exit() may have unpleasant effects...

[dmlloyd]

Also if the only way to inject args is via Arc, then I don't we will be able to incorporate Æsh

Good point...

[geoand]

For CDI injection of the main args, I guess changes would need to be made to Arc?

I don't think so (I'm not 100% sure though). The main class would have to expose the args somehow. But it's possible that the main method build step runs too late to produce a CDI bean build item.

Of the alternatives proposed for the exit strategy, I personally feel that the dedicated annotation is more natural. In that case could the rest of the infra put in place here be used? I mean that the generated bytecode would invoke the CLI method and then attempt to shutdown in a similar manner as is done here?

I'm not so sure. We want the user to be able to set the exit status. That's easy from an API perspective but it's difficult from the perspective that the user might be running this in dev mode, where calling System.exit() may have unpleasant effects...

Does dev mode make sense for these types of applications?

[dmlloyd]

Does dev mode make sense for these types of applications?

Perhaps not; I wonder if we can/should detect the case and give an error?

[geoand]

Perhaps not; I wonder if we can/should detect the case and give an error?

I was thinking the same thing.
I mean if we have an annotation that will be used to detect the method that the user intends to be used as an entry point to the command line invocation, then I would guess that we could fail when detecting such annotation and when the LaunchMode is Dev.
WDTY?

[dmlloyd]

Seems possible, want to give it a try?

[geoand]

@dmlloyd Sure thing, I can't get it done today because of regular team work, but I'll try to sneak in some time over the weekend 😉

[geoand]

I added a commit that makes dev mode fail when a command line application is used

[geoand]

@dmlloyd Do you think that the current form of the PR makes sense as something to build on? I am thinking that if it is, I can also rebase the Aesh work I did previously in another branch.

[dmlloyd]

I have a few doubts. Requiring an entire extension and everything else for this seems like way too much. It would be so much better if there was just a small extra bit of code to detect an annotation and then trigger the shutdown behavior if present, skipping the extra ApplicationImpl method and all the other extra generated bytecode.

[geoand]

I understand the concern, indeed.
However the advantage I see with the current approach is that it can support various use cases (like the command line runner being a bean, the Aesh approach were the user would write multiple command objects).
I will of course proceed however you see fit since you have much more experience in such matters 😉

[geoand]

@dmlloyd would you like me to add a poc of how Aesh could be added using this approach - maybe it will help show the benefits :P

[dmlloyd]

Sure, maybe there's something I'm not seeing about how Aesh operates.

[geoand]

@dmlloyd cool, I'll try to squeeze it in tonight then

[geoand]

@dmlloyd I added another extension that shows how Aesh could be utilized. It's pretty rudimentary, but it hopefully showcases the power of the current approach :)

It would definitely require some clean up, but I just wanted to show what's possible for the time being

[stalep]

the æsh part looks good i think. im planning on doing a pr tomorrow that will upgrade the cli to use æsh 2.0/2.1 as well so there wont be any version difference between devtools/aesh and this.

the idea of using æsh here is that the command line arguments are automatically verified and injected into the command. also, we can give the user access to a QuarkusContext object through the CommandInvocation which adds some fairly unique possibilities to access parts of quarkus without exposing any other api.

[geoand]

@dmlloyd Have you had a chance to look at how Aesh could benefit from the approach proposed in this PR?

[dmlloyd]

We should talk of this in terms of requirements, which is the "hidden" step between use case and implementation. What behaviors are required for adequate Aesh integration? This would be in addition to the basic stuff:

• Allow a program to declare that it exits immediately
• Provide a means of controlling the process exit code for immediate-exit programs
• Provide a means of consuming command line arguments (perhaps multiple times?)

[geoand]

@dmlloyd 👍

Should we setup a call perhaps with @stalep so he can give us his extensive Aesh perspective? My perspective is simply one of a Spring Boot developer used to consuming CommandLineRunner.

[dmlloyd]

Sure, a call sounds good. I think the Spring Boot perspective is valid also; we just want to capture any desirable aspects of that experience as usability requirements as well. Once all the requirements are in one place, implementations are easy to evaluate (and sometimes you discover new requirements in this process).

[geoand]

Sounds good. @dmlloyd @stalep Any preferences for when to schedule or should I just look at your calendars and find an empty slot? :)

[geoand]

I will close this for now. Once we have a consensus on the general strategy to be followed, I can work on it again if you like