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

server.xml assist does not provide diagnostics for incorrect attributes #186

Closed scottkurz closed 1 year ago

scottkurz commented 1 year ago

USE CASE

As one example,

take the fact that we have different "context root" attribute names e.g. we have:

<webApplication contextRoot="ctx"

but

<web-ext context-root="ctx"..

It would be nice to have LCLS validate this and provide a diagnostic at least (not sure a quick fix is possible, but the user could do Ctrl+Space to get a completion suggestion to fix easily enough themselves).

PROBLEM

However, the Liberty XSD generated is something like:

    <xsd:complexType name="com.ibm.ws.app.manager.webappcfg"> 
        ...
        <xsd:anyAttribute processContents="skip"/>

preventing the XSD from detecting this as invalid.

RUNTIME ISSUE LINK

This depends on https://github.com/OpenLiberty/open-liberty/issues/25579. Presumably we'd address in the runtime and then see what if anything would be needed to pick up the change in LCLS.

scottkurz commented 1 year ago

Though we have achieved consensus in https://github.com/OpenLiberty/open-liberty/issues/25579 to make a change, creating a new v3 output version w/o the anyAttributes (except for special types like those for JDBC driver props), this still presents a challenge for older runtime drivers (ones before the future change).

Is it possible it'd be better to have the LCLS do some "post-processing" on the XSD, which could thereby work for older runtimes as well?

Note the flow for older runtimes could be something like: upon git clone Liberty Tools validates against the stricter XSD (the LCLS default, which would presumably be the most updated one, at the v3 level), but after installing Liberty a runtime-specific schemaGen is performed (at the older v2 level). Do we like this?

One other note: after researching more, WDT/LDT actually detects unknown attributes using some custom XSD validation logic, e.g. rooted at: https://github.com/OpenLiberty/open-liberty-tools/tree/integration/dev/com.ibm.ws.st.core/src/com/ibm/ws/st/core/internal/config which dsiplays errors for attributes which are not known attributes, (in spite of the fact these are still XSD-valid, due to the anyAttribute).

scottkurz commented 1 year ago

2023-08-23 DXDI update - We still support the consensus in https://github.com/OpenLiberty/open-liberty/issues/25579 of adding a new v3 output version. We will rely on this v3 version for newer versions of Liberty (once the support is shipped in OL runtime), both for the Maven-published XSDs and ones generated dynamically from the server install.

We will also, however, look to add post-processing support to LCLS to fix up the v2-format XSDs and remove extra anyAttributes. This could allow for a solution to the high-level problem in the tooling, if the tooling delivers before the runtime change. And further, once the support is delivered into the runtime, this post-processing could still be used to validate XSDs generated from older runtimes.

cherylking commented 1 year ago

We will target the post-processing described above for the next feature release.

cherylking commented 1 year ago

I merged the xsd post processing in the 4q2023 branch.

cherylking commented 1 year ago

I am closing this issue since the post-processing of the cached and generated schema fixes this. Issue #203 is open to address using the published schemas once they are available.