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

[ELY-2343] Add a web option to the Elytron Tool #1715

Closed
wants to merge 1 commit into from

Conversation

petrberan
Copy link
Contributor

@petrberan
Copy link
Contributor Author

Hi @Skyllarr @fjuma can I ask for review please?

@fjuma
Copy link
Contributor

fjuma commented Dec 2, 2022

@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"));
Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Contributor

@Skyllarr Skyllarr Dec 8, 2022

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"

Copy link
Contributor

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!

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor

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.

@petrberan
Copy link
Contributor Author

@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

@petrberan
Copy link
Contributor Author

Hi @fjuma can I ask for review please?

@fjuma
Copy link
Contributor

fjuma commented Mar 16, 2023

@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.

@Skyllarr
Copy link
Contributor

@fjuma yes I checked it manually before and it was working well. But would be great for @cam-rod to try out as well

Copy link
Contributor

@jessicarod7 jessicarod7 left a 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!

@fjuma
Copy link
Contributor

fjuma commented Mar 16, 2023

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.

Thanks for trying that out! I think #1843 fixed the LogManager issue, this branch might need a rebase.

@bstansberry
Copy link

@petrberan @fjuma This ties the Elytron project to the WildFly project in new and problematic ways.

  1. The WildFly project doesn't make guarantees to the Elytron project regarding the structure of its documentation URLs, even for bits like the "WildFly_Elytron_Security" path element and subsequent anchors that are generally (but not entirely) under the control of people working on Elytron. Of course the two projects are intimately related and people cooperate, but this introduces a long term coordination requirement between the projects.

  2. It creates a chicken and egg problem. For example "27" is not the correct value for the Elytron release that would include this work. Once WF 28 is released, Elytron would need to change to 28, but that would be wrong too, as that changed code would go into 29. The "27" is sure to be an issue, but a similar problem would apply if WildFly made any change to its docs URLs that impact what's done here.

  3. It ties use of Elytron to WildFly. But Elytron is used in other contexts, e.g. JBoss EAP.

@Skyllarr
Copy link
Contributor

Skyllarr commented Mar 24, 2023

@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.

@fjuma
Copy link
Contributor

fjuma commented Mar 27, 2023

@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.

@petrberan
Copy link
Contributor Author

@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

@petrberan
Copy link
Contributor Author

Hi @fjuma just sending a reminder about his PR

@fjuma
Copy link
Contributor

fjuma commented Dec 22, 2023

Hi @petrberan, thanks for the reminder and apologies for the delayed response. There have been a lot of discussions recently about having a latest URL for the WildFly docs (which would prevent us from having to update the URL for each release), a new Guides page for wildfly.org, etc. However, as was pointed out before, these options would still result in us depending on the WildFly project which isn't ideal.

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:

https://wildfly-security.github.io/wildfly-elytron/documentation/api/next/org/wildfly/security/tool/package-summary.html

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?

@fjuma
Copy link
Contributor

fjuma commented Dec 22, 2023

Just a reminder for the new year, please update this PR so it's against the 2.x branch. Thanks!

@ivassile
Copy link
Contributor

@petrberan Can you please update the PR to be against 2.x? Thanks!

@ivassile
Copy link
Contributor

@petrberan Can you please update the PR to be against 2.x so we can proceed? Thanks!

@rsearls
Copy link
Contributor

rsearls commented Sep 18, 2024

This very old PR has been rebased to 2.x current. The update has been submitted
as new PR #2198

This PR can be closed.

@fjuma
Copy link
Contributor

fjuma commented Sep 18, 2024

Thanks @rsearls, closing this one.

@fjuma fjuma closed this Sep 18, 2024
@petrberan
Copy link
Contributor Author

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

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

Successfully merging this pull request may close these issues.

8 participants