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

Debugger does not attach to server when using a custom liberty installation #415

Open
mezarin opened this issue May 18, 2023 · 6 comments · May be fixed by #710
Open

Debugger does not attach to server when using a custom liberty installation #415

mezarin opened this issue May 18, 2023 · 6 comments · May be fixed by #710
Assignees
Labels
5 Estimated story points bug Something isn't working design parity Concern re: parity/commonality among Liberty Tools IDEs: Eclipse,VSCode,IDEA should-fix
Milestone

Comments

@mezarin
Copy link
Member

mezarin commented May 18, 2023

When running a Maven/Gradle build application that requires a custom liberty installation path or usr directoy, the debugger fails to attach to the server's JVM.

Here are some scenarios using a Maven built application:

Scenario 1: Using a custom wlp installation

a. Install/download a wlp at your desired location (i.e.: /Users/.../singleModMavenMP/myintalldir)
b. Add the installDirectory parameter to a maven test app’s pom.xml:

            <plugin>
                <groupId>io.openliberty.tools</groupId>
                <artifactId>liberty-maven-plugin</artifactId>
                <version>3.7.1</version>
                <configuration>
                    <installDirectory>
                        /Users/.../singleModMavenMP/myinstalldir/wlp
                    </installDirectory>
                </configuration>
            </plugin>

c. Kick off dev mode in debug mode. After some time, an error is reported.

Scenario 2: Using an auto installed wlp at a custom location.

a. Add the runtimeInstallDirectory entry to a maven test app’s pom.xml:

            <plugin>
                <groupId>io.openliberty.tools</groupId>
                <artifactId>liberty-maven-plugin</artifactId>
                <version>3.7.1</version>
                <configuration>
                    <runtimeInstallDirectory>
                        /Users/.../singleModMavenMP/myinstalldir
                    </runtimeInstallDirectory>
                </configuration>
            </plugin>

b. Kick off dev mode in debug mode. Similar to the first case, after some time, you get an error. In this case, the auto installed wlp is located in in a custom location: /Users/…/singleModMavenMP/myinstalldir.

Scenario 3: Using an auto installed wlp with a the usr directory at a custom location

a. Add the userDirectory parameter to a maven test app’s pom.xml:

            <plugin>
                <groupId>io.openliberty.tools</groupId>
                <artifactId>liberty-maven-plugin</artifactId>
                <version>3.7.1</version>
                <configuration>
                    <userDirectory>
                        /Users/.../singleModMavenMP/myusrdir
                    </userDirectory>
                </configuration>
            </plugin>

b. Kick off dev mode in debug mode. Similar to the first case, after some time you get an error. In this case, the wlp installation is located in the default place, but the servers’ data is sent to /Users/…/singleModMavenMP/myusrdir.

image

@TrevCraw TrevCraw added the bug Something isn't working label May 18, 2023
@TrevCraw TrevCraw added this to the GA milestone May 18, 2023
@TrevCraw TrevCraw added the documentation Improvements or additions to documentation label Jun 15, 2023
@TrevCraw TrevCraw removed the documentation Improvements or additions to documentation label Jul 24, 2023
@dessina-devasia dessina-devasia self-assigned this Nov 21, 2023
dessina-devasia added a commit to dessina-devasia/liberty-tools-intellij that referenced this issue Dec 12, 2023
dessina-devasia added a commit to dessina-devasia/liberty-tools-intellij that referenced this issue Dec 22, 2023
…custom liberty in case of maven and gradle projects
dessina-devasia added a commit to dessina-devasia/liberty-tools-intellij that referenced this issue Dec 22, 2023
…custom liberty in case of maven and gradle projects
@TrevCraw
Copy link
Contributor

As per discussions with @mrglavas and @turkeylurkey , the new strategy for retrieving the custom directory containing the server.env will be to find the custom install directory in the target/liberty-plugin-config.xml file which is generated by the Liberty build plugins when the project is built.

This will be more straightforward than parsing through the pom.xml, as there can be different permutations and layers for defining configuration. It is also a single solution for both Maven and Gradle projects, so we don’t need to figure out a separate solution for Gradle. It is also a solution that can be applied across each of the IDEs for Liberty Tools.

We still need to determine the precedence for the properties that we use to find the custom location of the server.env (ie. runtimeInstallDirectory vs installDirectory vs userDirectory). There are also some synchronization concerns that will need to be addressed (ie. is the liberty-plugin-config.xml file done being written to when we go to read from it).

@TrevCraw TrevCraw added the 5 Estimated story points label Jan 16, 2024
@TrevCraw TrevCraw added the parity Concern re: parity/commonality among Liberty Tools IDEs: Eclipse,VSCode,IDEA label Jan 17, 2024
dessina-devasia added a commit to dessina-devasia/liberty-tools-intellij that referenced this issue Jan 23, 2024
dessina-devasia added a commit to dessina-devasia/liberty-tools-intellij that referenced this issue Jan 25, 2024
@TrevCraw
Copy link
Contributor

TrevCraw commented Jan 31, 2024

Steps left to complete for this issue:

  • Resolve the debug action error
  • Handle scenario 1
  • Handle scenario 2
  • Handle scenario 3
  • Investigate how to handle any combination of properties from scenarios 1, 2 and 3
  • Handle synchronization concerns
  • Add automated test to cover this scenario

dessina-devasia added a commit to dessina-devasia/liberty-tools-intellij that referenced this issue Feb 2, 2024
dessina-devasia added a commit to dessina-devasia/liberty-tools-intellij that referenced this issue Feb 2, 2024
dessina-devasia added a commit to dessina-devasia/liberty-tools-intellij that referenced this issue Feb 2, 2024
@scottkurz
Copy link
Member

I'm not sure I'm remembering totally correctly... but my recollection is that as @mezarin was working on the similar function in Liberty Tools Eclipse this ended up being a less important issue or even non-issue?

I think the key is that we decided to basically not care about the contents of server.env. We decided to generate a random port from LT itself.

More precisely, I think we decided to generate a -DdebugPort=<gen'd number> after first looking at the custom parms and determining the custom parms didn't include one. But I don't think we care to say look at server.env for a WLP_DEBUG_ADDRESS entry. I guess because our CLI parm overrides? @mezarin am I capturing this correctly? Anything you could add here? (Thank you)

@mezarin
Copy link
Member Author

mezarin commented Feb 7, 2024

@scottkurz, I believe the removal of the code that used server.env from Liberty Tools for Eclipse was mostly an effort to reduce complexity given that a random port would work for the most part. See PR 292.
What Liberty Tools for Intellij is trying to accomplish with this is to further close the gap when another process can take the random port between the time the random port is selected and we actually connect to it.

@TrevCraw
Copy link
Contributor

TrevCraw commented Feb 7, 2024

As discussed on the DXDI call, synchronization for when we read the liberty-plugin-config.xml may not be a major concern, since worse case scenario is the debugger fails to attach and we can try again (ie. retrieve the port from server.env a second time)

dessina-devasia added a commit to dessina-devasia/liberty-tools-intellij that referenced this issue Feb 21, 2024
…dded 2 sample projects for gradle and maven to test the custom liberty installation
dessina-devasia added a commit to dessina-devasia/liberty-tools-intellij that referenced this issue Feb 21, 2024
…l-maven-app and custom-liberty-install-gradle-app)
dessina-devasia added a commit to dessina-devasia/liberty-tools-intellij that referenced this issue Feb 21, 2024
dessina-devasia added a commit to dessina-devasia/liberty-tools-intellij that referenced this issue Apr 8, 2024
dessina-devasia added a commit to dessina-devasia/liberty-tools-intellij that referenced this issue Apr 9, 2024
dessina-devasia added a commit to dessina-devasia/liberty-tools-intellij that referenced this issue Apr 9, 2024
dessina-devasia added a commit to dessina-devasia/liberty-tools-intellij that referenced this issue Apr 12, 2024
@aparnamichael
Copy link
Contributor

  • Development and testing completed for both maven and gradle
  • Development and testing completed for all the scenarios mentioned in the issue
  • Development and testing completed for all the combinations of the scenarios as well
  • Automated test coverage completed for all the scenarios and its combinations for both maven and gradle.
  • UI test success for all cases of maven
  • UI test failed for gradle as it is failed to attach debugger during testing

Next steps

  • Connect with the custom WLP folder in GitHub
  • Resolve the test failure for gradle

@TrevCraw TrevCraw modified the milestones: GA, 24.0.7 May 17, 2024
@TrevCraw TrevCraw modified the milestones: 24.0.7, Next Jun 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
5 Estimated story points bug Something isn't working design parity Concern re: parity/commonality among Liberty Tools IDEs: Eclipse,VSCode,IDEA should-fix
Projects
6 participants