-
Notifications
You must be signed in to change notification settings - Fork 279
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
[ELY-2343] Add a web option to the Elytron Tool #1715
Conversation
@petrberan Sorry for the delay! We will try to take a look next week. Thanks! |
Desktop desktop = Desktop.getDesktop(); | ||
if (desktop.isSupported(Desktop.Action.BROWSE)){ | ||
try { | ||
desktop.browse(new URI("https://docs.wildfly.org/26.1/WildFly_Elytron_Security.html#CredentialStore")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@petrberan Just a minor, since the version is in each URL and it will have to be updated in the future, it would be better to have it parametrized. Also https://docs.wildfly.org
can be made into a constant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Skyllarr Good point. Do you know what would be a good way to pass the parameter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@petrberan Sorry I might have used a wrong word. I did not mean adding a parameter to the elytron tool that would specify the version. That would get more complicated to specify the version when using the tool with EAP for example etc. I meant it's better to make a constant out of "https://docs.wildfly.org" and eg. DOCS_VERSION="27"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@petrberan Otherwise this PR LGTM, thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Skyllarr I was also wondering how the version would pass from WFLY to WFCORE and then to ELY. Created a constants for the doc URI in each command class, should be alright now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'd need to remember to update the DOCS_VERSION after each WildFly release. It would be nice if there was a latest
URL that we could point to instead but I don't think we have something like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fjuma When using tool with EAP, it is okay that it directs users to wildfly docs instead of EAP right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's see what @OndrejKotek thinks when he's back from PTO.
We also need to check with @OndrejKotek to see if he thinks this should be handled as an RFE since it introduces a new option for Elytron Tool.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding upstream docs in product. I'm not sure, asking higher instances. However, I think there should be a possibility to change the URLs easily, e.g. by building with a provided properties file with URLs.
Regarding having the WF version (and maybe even doc URL) hard-coded. Can this parametrization be moved a bit closer to releasing so that we don't forget to update to the latest? E.g. as property in pom.xml? Or as a properties file maintained along to WF documentation, referenced in pom.xml?
Regarding RFE process. The change is quite simple, however if we would go the way with different URLs for the product we needed some agreements and tests. Maybe still doable in scope of an JBEAP. Let's discuss this on the next Ely team meeting.
@Skyllarr @fjuma Looking at the command classes and how some of the them share the same constants, what is your opinion on creating some form of ElytronToolConstants class that would contain all constants for the Tool commands? Got this idea when copying the same URI and docs version for 4 classes as the parent Command class was a bad place to hold the constant. That way - for example when changing the version of docs - you don't have to change 5 classes but just 1. In case that's a good idea, feel free to create a new JIRA issue and assign it to me |
Hi @fjuma can I ask for review please? |
@Skyllarr Just to check, have you tried this out manually? @cam-rod If you have some time and could try this out as well, that would be great. |
@fjuma yes I checked it manually before and it was working well. But would be great for @cam-rod to try out as well |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested it with the shaded JAR, looks good! A couple things I noticed:
- This error message appeared each time. I'm not sure if it's due to me using the shaded JAR or something else, but it didn't appear when running
--help
Mar 16, 2023 4:42:02 PM org.jboss.logmanager.JBossLoggerFinder getLogger ERROR: The LogManager accessed before the "java.util.logging.manager" system property was set to "org.jboss.logmanager.LogManager". Results may be unexpected. Opening in existing browser session.
- Tested in a container to try when a browser isn't available, didn't seem to lead to major errors. The error message
java.io.IOException: Unable to open the browser.
only appeared when using the--debug
flag, it might be nicer to show that all the time.
Otherwise, nice work!
Thanks for trying that out! I think #1843 fixed the LogManager issue, this branch might need a rebase. |
@petrberan @fjuma This ties the Elytron project to the WildFly project in new and problematic ways.
|
@fjuma @bstansberry Just an idea to throw out there. Maybe we could create a short blog posts on https://wildfly-security.github.io/wildfly-elytron/blog/ for each of the tool commands and that would be where the web option would point. The URL of our blogs is under our control and should not be changing any time soon, and we can make edits to the posts without waiting for releases. Disadvantage still is that users, mostly Jboss EAP users, would expect proper documentation links instead of blog posts, and we would not make new posts for each WF release so on older versions it could have missing options. |
@bstansberry @Skyllarr Thanks for the feedback here! The Elytron website has a Guides section. Building on @Skyllarr's idea, that might be an option as well, i.e., add guides for Elytron Tool commands to our website. These could be kept up to date as changes are made. Just something to consider. But we'd still want a way to replace the URL. |
@fjuma Getting back to this again. Wouldn't it make sense to have the help in the Docs section on the web - https://wildfly-security.github.io/wildfly-elytron/docs/ ? There it could be even split into versions, the version in the command would either change depending on the string or it could be derived from the version in pom.xml |
Hi @fjuma just sending a reminder about his PR |
Hi @petrberan, thanks for the reminder and apologies for the delayed response. There have been a lot of discussions recently about having a The docs page you mentioned (https://wildfly-security.github.io/wildfly-elytron/docs/) points to the JavaDoc for Elytron so that could be a good candidate. The Elytron Tool commands are private API, their JavaDoc appears here: We could potentially update the JavaDoc to add more details and then the web option could point there. That way, this would be under our control and as you mentioned, this would be versioned. @petrberan @Skyllarr WDYT? |
Just a reminder for the new year, please update this PR so it's against the 2.x branch. Thanks! |
@petrberan Can you please update the PR to be against 2.x? Thanks! |
@petrberan Can you please update the PR to be against 2.x so we can proceed? Thanks! |
This very old PR has been rebased to 2.x current. The update has been submitted This PR can be closed. |
Thanks @rsearls, closing this one. |
Thanks for opening a PR for 2.x @rsearls . I originally waited for update on to where this option should point to, which I don't think I see and Wildfly documentation for version 27 seems outdated after 2 years since this PR was opened. Still can't find where the link in there should lead, sadly. Also please bear in mind that this PR requires wildfly/wildfly-core#5124 if I'm not mistaken |
https://issues.redhat.com/browse/ELY-2343