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

ARTEMIS-4372 Implement Pico-cli and script auto-complete #4565

Merged
merged 1 commit into from
Jul 31, 2023

Conversation

clebertsuconic
Copy link
Contributor

No description provided.

@clebertsuconic clebertsuconic marked this pull request as draft July 24, 2023 17:43
@clebertsuconic clebertsuconic marked this pull request as ready for review July 26, 2023 15:25
@gemmellr
Copy link
Member

I have added one more review from myself. When using user/password the system would ask me for the user/password all the time. I'm now saving the last successful user/password between executions, adding a connect and disconnect that's only available through the shell (what makes the shell more useful since it won't ask for user/password every time when using security)

I think the ability to set and clear the URI + credentials used for subsequent commands in the shell is good. I'm less clear on it doing it silently in the background based on every previous command.

At least one of the additions you made was around it handling the URIs crossing between the different clients, presumably as the URI is saved but the protocol value is not, probably how you hit that, the client used will change between commands in some cases, whilst the URI + credentials etc do not even though the URIs are client-specific.

@clebertsuconic
Copy link
Contributor Author

for my future reference. I opened an issue and Pull Request on Pico: remkop/picocli#2075

the jshell auto completion is showing hidden values. the PR sent would fix it but I'm waiting for a best way to merge this upstream in Pico. hidden is the way to go to "deprecate" stuff.

@clebertsuconic
Copy link
Contributor Author

Only thing left on my todo is the JDK parameters and testing with a newer version. will do it before the end of today.

gnodet
gnodet previously requested changes Jul 31, 2023
Copy link
Contributor

@gnodet gnodet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to add jansi library, which is an optional dependency of JLine for better support.

artemis-cli/pom.xml Show resolved Hide resolved
Comment on lines 94 to 96
--add-opens java.base/java.lang=ALL-UNNAMED \
--add-opens java.base/java.io=ALL-UNNAMED \
--add-opens java.base/java.util=ALL-UNNAMED \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above, adding jansi will remove the need for those options.

@clebertsuconic clebertsuconic dismissed gnodet’s stale review July 31, 2023 13:01

I did the change manually.. thank you so much

ARTEMIS-4375 Implement artemis shell using JLine3 integrated with auto-completion from picocli

This commit involves two JIRAs. One is adding PicoCLI and the next is Using JLine3 and implement a shell.
I have tried to keep these commits separate but these changes became interdependent hence the two JIRAs are squashed in this commit.
@clebertsuconic
Copy link
Contributor Author

@gemmellr I am merging this... further changes can be sent into main after this.

Thanks for your help on this

@clebertsuconic clebertsuconic merged commit 93ee61e into apache:main Jul 31, 2023
3 of 6 checks passed
Comment on lines +271 to +272
} catch (Exception e2) {
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one does nothing, the earlier ones for Qpid JMS print the stack. Seems like they should be the same one way or the other.

Comment on lines +288 to +289
} catch (Exception e2) {
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not really in both cases.. This is the exception of the exception. IN case the input user/password does not succeed, if this does not work this will simply not save the password here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what you mean now.

Comment on lines +150 to +151
context.out.println("--txt-size is deprecated, please use --commit-interval");
txBatchSize = oldBatchSize;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If both were somehow set, I would expect the new one to always win...here the old one will win.

Comment on lines +74 to +77
if (txSize > 0) {
System.out.println("--tx-size is deprecated, please use --commit-interval");
commitInterval = txSize;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If both were somehow set, I would expect the new one to always win...here the old one will win.


// Pico shouldn't allow generating a commandLine without an userObject.
// the following assert "should" never happen
assert userObject != null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good chance the assert also wont happen unless people turn on assertions. Seems like a null check would have been simpler. Though it will at least still NPE later, when failing to throw the IAE.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is never supposed to happen.
Only chance userObject is null is if you set the userObject wrongly during development. and picocli actually validate that already.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough. You didnt note the last bit before, just that 'we shouldnt add things that arent Runnable or Action', then you added the fallback check which would NPE if it was null, which I then noted. I'd still have just added a simple Objects.nonNull("oh-dear developer-error", userObject) rather than the multi line assert+comment that quite posibly still wont do anything and allow the raw NPE to occur.

@clebertsuconic clebertsuconic deleted the pico branch August 14, 2023 16:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants