IBM Liberty Developer Tools lose settings on each Eclipse start

[dougbreaux]

Eclipse 2023-06 currently, but has been occurring on earlier versions for at least a year. "IBM Liberty Developer Tools 23.1" (earlier last year). Semeru JDK 11. Windows.

Both the Liberty installation directory and the selected runtime revert back to their initial values rather than retaining the last ones I'd set and saved. Even when the original directory or runtime no longer exist.

I'll attach some screenshots and messages from both an instance I recorded 2022-10 and today, 2023-09.

2022-10

A problem has occurred while generating information for runtime environment Cannot run program "C:\Program Files\Semeru\jdk-11.0.16.8-openj9\bin\java" (in directory "C:\java\wlp\bin\tools"): CreateProcess error=267, The directory name is invalid. Try refreshing the runtime environment cache to resolve this issue.

2023-09

[mattcolegate]

Can you give us the .log from your workspace folder please?

[dougbreaux]

This behavior continues and is consistent every time I start Eclipse. Is there some secure way to provide my .log file? In case there's anything sensitive in it.

[dbarfield]

Let me have a go at reproducing first if that is a potential issue.

[dbarfield]

@dougbreaux Hello Doug, I think we are missing some information here and are unable to reproduce the issue. Let me go through my reproduction steps and please tell me where your steps differ (note that this is only looking at the runtime being lost at the moment to reduce complexity):

1. Install eclipse and install Open Liberty Tools.
2. Unzip two open liberty runtimes runtimes and name them "ol1" and "ol2"
3. Using the "Runtime Explorer" view, define a Liberty Runtime pointing at "ol1" (or optionally define a runtime for "ol2" as well)
4. Right click on runtime > New Liberty Server "Fred" (which will be created in the usr directory of "ol1")
5. Right click on Fred and select new server
6. [optional] Switch to "Servers" view and start and stop server "Fred"
7. From "Servers" select Fred and press F3
8. EITHER click "Runtime Environment" and change the runtime location to "ol2" OR if you defined the 2nd runtime on use the pull down to select the other runtime.
9. Save the server pane (CTRL+S)
10. Exit eclipse
11. Rename "ol1" to "ol1-delete"
12. Start eclipse
13. From "Runtime Explorer" view the runtime is still pointing at the new runtime location.
14. From "Server" view start server and get the expected message back saying that the server does not exist (as it exists under the usr directory of the old runtime).

How does your recreation differ ?

[dougbreaux]

1. IBM Liberty Developer Tools 23.2. Just to be certain we're talking about the same extension
2. yes
3. I didn't use the "Runtime Explorer" view, but I expect what I did is effectively the same? Servers view > Runtime Environment > Choose an existing installation (will attach screenshot)
4. I've been working with an existing server, not creating a new one, for a long time
5. ditto
6. I start and stop server often after switching the Runtime Environment
7. don't know what F3 does, haven't used it
8. yes
9. yes
10. yes
11. deleted folder entirely
12. yes
13. no, it's pointing to the old that doesn't exist. Further, the JRE is pointing back to the prior/outdated value (which in my case doesn't exist either). I have to switch both again to current values
14. before I switch back, when starting Eclipse, I get the original screenshot shown

Dialog from step 3:

Additional, possibly-relevant detail: I have defined the usr directory as a location external to the product installations. So that I don't lose configuration when I upgrade:

[dbarfield]

Okay my apologies you did say "Liberty Developer Tools" not "Open Liberty Tools" I did try originally with the "WebSphere Developer Tools" which includes "Liberty Developer Tools" and the tradtional "WebSphere Tools" ... will try those notes and see if I can get any closer.

F3 on the server definition just brings up the server overview which is how I thought you got to the edit options.

[dougbreaux]

Still happening on an entirely new system, but where I'd copied the workspace over from my prior system.

Trying to get to the bottom of this, I find a couple of files in workspace > .metadata > .plugins > org.eclipse.core.runtime > .settings that do contain the obsolete paths:

• com.ibm.ws.st.ui.prefs
• org.eclipse.wst.server.core.prefs

Manually cleaning up these does seem to have resolved the problem. So, the question is why they're not being preserved when the represented settings are edited from within Eclipse.

Oh, including making the vm-install-id in the second match the <vm id in org.eclipse.jdt.launching.prefs. Selecting the VM in the dialog apparently doesn't update this file either.

[dougbreaux]

Well, I just added a new location from the UI, and I see it updated in the com.ibm.ws.st.ui.prefs file. I'll have to see if it persists on shutdown/restart

[dougbreaux]

Upon restart, ui.prefs kept the full list, but core.prefs reverted to the prior default