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

[mezarin]

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.

[TrevCraw]

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]

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

[scottkurz]

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]

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

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)

[aparnamichael]

• 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