-
Notifications
You must be signed in to change notification settings - Fork 25
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
Comments
…custom liberty in case of maven and gradle projects
…custom liberty in case of maven and gradle projects
As per discussions with @mrglavas and @turkeylurkey , the new strategy for retrieving the custom directory containing the 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 |
…fore running the server
Steps left to complete for this issue:
|
…lue from liberty-plugin-config
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 |
@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. |
As discussed on the DXDI call, synchronization for when we read the |
…dded 2 sample projects for gradle and maven to test the custom liberty installation
…l-maven-app and custom-liberty-install-gradle-app)
Next steps
|
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:
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:
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:
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.
The text was updated successfully, but these errors were encountered: