search

OpenLiberty / liberty-language-server

The Liberty Config Language Server provides language server features for Liberty server configuration files through any of the supported client IDEs.
Eclipse Public License 2.0
6 stars 12 forks source link

Project imported after Lemminx extension initialized (accessing other project) gets stuck with generic server.xsd rather than install-specific versioned XSD #82

Open scottkurz opened 2 years ago

scottkurz commented 2 years ago

RECREATE

  1. git clone git@github.com:OpenLiberty/application-stack-intro.git; cd application-stack-intro
  2. mvn liberty:create
  3. In Eclipse, Import as Existing Maven project
  4. Open src/main/liberty/config/server.xml
  5. With mouse cursor, hover over <featureManager> element. Observe light yellow box with last line: `Source: ol-22.0.0.7.xsd' (or whatever most recent version is).
  6. In a separate directory: git clone git@github.com:OpenLiberty/guide-getting-started.git; cd guide-getting-started/finish
  7. mvn liberty:create
  8. In Eclipse, Import as Existing Maven project
  9. Open src/main/liberty/config/server.xml
  10. With mouse cursor, hover over <featureManager> element. Observe light yellow box with last line: Source: server.xsd (hyperlinked to generic Lemminx-cached XSD)

Note if you close and restart the Eclipse IDE and repeat the hover in the second project you will now see the "Source:" pointing to the specific Liberty version XSD.

Thoughts

In debugger, problem seems related to using a singleton LibertyProjectsManager and loading uprfront via LibertyExtension.

Not sure how bad it would be to simply not rely on caching.. e.g. look at all the projects somehow.

Let me note that if you end up thinking there needs to be a code hook into project import... Liberty Tools is likely to design a hook like that going forwards.. .so possibly you'd want to hook into the LT hook rather than some other??? IDK..just noting this as one possible avenue.

mattbsox commented 2 years ago

The correct XSD version is also displayed if both server.xml files are closed and the second server.xml is reopened. No Eclipse restart needed.

scottkurz commented 2 years ago

The correct XSD version is also displayed if both server.xml files are closed and the second server.xml is reopened. No Eclipse restart needed.

Watching in the debugger it seems like the entire Lemminx LS process got shut down when all open XML files were closed, so yes it was completely re-initialized. Wondering if we can follow the pattern of https://github.com/eclipse/lemminx-maven/blob/master/lemminx-maven/src/main/java/org/eclipse/lemminx/extensions/maven/MavenLemminxExtension.java and get updated on new projects?

cherylking commented 1 year ago

Just noting here that this scenario works fine in Liberty Tools for Visual Studio Code. I have not verified IntelliJ yet.

scottkurz commented 11 months ago

@cherylking I was just checking in on this issue and saw this:

Just noting here that this scenario works fine in Liberty Tools for Visual Studio Code. I have not verified IntelliJ yet.

Is this an apples-to-apples comparison though, in VSCode? If I open a 2nd project doesn't it just create a new VSCode and new Lemminx?

BTW, I don't think this is a giant issue because the cached XSD gets us so much.

Though on the chance someone really is expecting the custom XSD based on their install, then it's going to be pretty frustrating..so maybe a medium priority in all.

cherylking commented 11 months ago

Is this an apples-to-apples comparison though, in VSCode? If I open a 2nd project doesn't it just create a new VSCode and new Lemminx?

@scottkurz If you are talking about the workspace in VS Code, then you are probably right. But you can also add new folders to the existing workspace in VS Code, and it handles the initialization just fine from what I have seen.