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
5 stars 11 forks source link

While testing 'Start in container' using podman, generating an empty .libertyls folder in Mac OS. #253

Closed aparnamichael closed 9 months ago

aparnamichael commented 9 months ago

OS: Mac VS code: 1.84.2 Start in container using docker: everything working as expected.

While testing start in container using podman empty .libertyls folder is generating and server.xml is taking default cached 23.0.0.9.xsd file.

In server.xml, I am getting feature, loggging, keystore etc.. but list of features completion/hover info is not getting and diagnostics is not working after running start in container using podman. Tested with both gradle and maven project, in both I am seeing this same issue.

image

image

image

aparnamichael commented 9 months ago

Logs: `[Info - 20:58:21] Nov 20, 2023 08:58:21 org.eclipse.lemminx.XMLLanguageServer initialize() Message: Initializing XML Language server LemMinX Server info:

[Error - 20:59:27] Nov 20, 2023 08:59:27 io.openliberty.tools.langserver.lemminx.LibertyXSDURIResolver resolve() Message: Error: Unable to generate the Liberty schema from the target Liberty runtime: Cannot run program "docker": error=2, No such file or directory [Info - 20:59:27] Nov 20, 2023 08:59:27 io.openliberty.tools.langserver.lemminx.LibertyXSDURIResolver resolve() Message: Using cached Liberty schema file located at: /Users/aparnacmichael/.lemminx/cache/https/github.com/OpenLiberty/liberty-language-server/blob/master/lemminx-liberty/src/main/resources/schema/xsd/liberty/server-cached-23.0.0.9.xsd

`

cherylking commented 9 months ago

I will transfer to the LCLS repo. It seems that it is trying to use docker to generate the schema when it should be using podman. Not sure of the root cause yet. Will look to fix in next fix release.

scottkurz commented 9 months ago

I debugged and I think I see the problem... there's a mismatch btw. the XML the LMP is writing: using <containerEngine>

$ cat ./target/defaultServer-liberty-devc-metadata.xml
<?xml version="1.0" ?><devcModeMetaData><containerEngine>podman</containerEngine><containerName>liberty-dev</containerName><containerAlive>true</containerAlive></devcModeMetaData>

and the JAXB looking for <containerType>

@XmlRootElement(name = "devcModeMetaData")
@XmlAccessorType(XmlAccessType.FIELD)
public class DevcMetadata {
    public String getContainerType() {
        return containerType;
    }
    public void setContainerType(String containerType) {
        this.containerType = containerType;
    }

so it maps to 'null' and we dflt to docker

cherylking commented 9 months ago

@mattbsox I decided to just go ahead and make the change in ci.common instead. Please see referenced PR above.

cherylking commented 9 months ago

@aparnamichael The 3.10-SNAPSHOT for the maven plugin (and 3.7.1-SNAPSHOT for gradle) have been updated with a fix for this.

aparnamichael commented 9 months ago

I have tested with new snapshot and it is working fine for me. image