fix(amazonq): serve webview assets without Jetty PathResource (#560)

[laileni-aws]

Problem

Closes#560.

On Eclipse 2026-06 (4.40.0) the Amazon Q chat (and login) view renders as a blank screen. The webview asset server throws:

java.nio.file.InvalidPathException: Invalid PathInContext: /amazonq-ui.js
...
Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 2:
/C:/Users/<user>/eclipse-workspace/.metadata/.plugins/amazon-q-eclipse/lsp/AmazonQAgentic/1.70.0/clients/amazonq-ui.js
at java.base/sun.nio.fs.WindowsPathParser.normalize(...)
at java.base/java.nio.file.Path.resolve(Path.java:516)
at org.eclipse.jetty.util.resource.PathResource.resolveSchemeSpecificPath(PathResource.java:315)
at org.eclipse.jetty.util.resource.PathResource.resolve(PathResource.java:296)

Root cause

WebviewAssetServer served the LSP-provided UI directory through Jetty's ResourceHandler + setBaseResource(<dir>). To serve a request such as GET /amazonq-ui.js, Jetty resolves the request path against the base resource via PathResource#resolve.

The Jetty version the plugin builds against (12.0.9, Eclipse 2024-06) implemented this with Paths.get(resolvedUri), which correctly handles a Windows file:///C:/... URI. The newer Jetty bundled with Eclipse 4.40.0 changed PathResource#resolve to delegate to resolveSchemeSpecificPath(...), which combines the request into a URI-style string (/C:/Users/.../amazonq-ui.js) and passes it to Path#resolve(String). On Windows that string is rejected — : is illegal at index 2 because of the leading / before the drive letter — so no asset is ever served and the webview stays blank.

Because the broken code lives in the Jetty bundle supplied by the Eclipse target platform, we can't fix it there; the plugin must stop relying on PathResource#resolve.

Fix

Replace the ResourceHandler with a small Handler.Abstract (StaticFileHandler) that serves files from the asset directory using java.nio:

• resolves the request path relative to the base directory (baseDir.resolve(relativePath)), so the resulting path never contains a leading-slash + drive-letter sequence and stays valid on every platform;
• keeps a path-traversal guard (resolved.startsWith(baseDir));
• advertises content types by file extension (text/javascript, text/css, …).

The public API of WebviewAssetServer (resolve, getUri, stop), the ContextHandler, context path /, and the 127.0.0.1 virtual-host restriction are all unchanged, so ChatWebViewAssetProvider and ToolkitLoginWebViewAssetProvider need no changes.

org.eclipse.jetty.http (already a transitive dependency of org.eclipse.jetty.server) is added to Require-Bundle for HttpHeader / HttpStatus.

Testing

Added WebviewAssetServerTest (JUnit 5):

• getContentType resolution (known extensions, case-insensitivity, unknown / missing extension fallback);
• HTTP round-trip against the started server: serves a JS asset with the correct content type, serves a nested asset, and returns 404 for a missing asset.

Verified locally against the real Jetty 12.0.9 API (the version the plugin builds against):

• javac -Xlint:all compiles cleanly;
• all 5 tests pass;
• Checkstyle (10.23.1, plugin/checkstyle.xml) reports no violations.

Note: I was unable to run the full mvn package Tycho build in my environment; the GitHub Actions sanity build will exercise it on this PR. The fix itself addresses a Windows-only code path; the regression test runs on all platforms and confirms the new serving mechanism works.

[laileni-aws]

Problem

Closes#560.

On Eclipse 2026-06 (4.40.0) the Amazon Q chat (and login) view renders as a blank screen. The webview asset server throws:

java.nio.file.InvalidPathException: Invalid PathInContext: /amazonq-ui.js
...
Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 2:
/C:/Users/<user>/eclipse-workspace/.metadata/.plugins/amazon-q-eclipse/lsp/AmazonQAgentic/1.70.0/clients/amazonq-ui.js
at java.base/sun.nio.fs.WindowsPathParser.normalize(...)
at java.base/java.nio.file.Path.resolve(Path.java:516)
at org.eclipse.jetty.util.resource.PathResource.resolveSchemeSpecificPath(PathResource.java:315)
at org.eclipse.jetty.util.resource.PathResource.resolve(PathResource.java:296)

Root cause

WebviewAssetServer served the LSP-provided UI directory through Jetty's ResourceHandler + setBaseResource(<dir>). To serve a request such as GET /amazonq-ui.js, Jetty resolves the request path against the base resource via PathResource#resolve.

The Jetty version the plugin builds against (12.0.9, Eclipse 2024-06) implemented this with Paths.get(resolvedUri), which correctly handles a Windows file:///C:/... URI. The newer Jetty bundled with Eclipse 4.40.0 changed PathResource#resolve to delegate to resolveSchemeSpecificPath(...), which combines the request into a URI-style string (/C:/Users/.../amazonq-ui.js) and passes it to Path#resolve(String). On Windows that string is rejected — : is illegal at index 2 because of the leading / before the drive letter — so no asset is ever served and the webview stays blank.

Because the broken code lives in the Jetty bundle supplied by the Eclipse target platform, we can't fix it there; the plugin must stop relying on PathResource#resolve.

Fix

Replace the ResourceHandler with a small Handler.Abstract (StaticFileHandler) that serves files from the asset directory using java.nio:

• resolves the request path relative to the base directory (baseDir.resolve(relativePath)), so the resulting path never contains a leading-slash + drive-letter sequence and stays valid on every platform;
• keeps a path-traversal guard (resolved.startsWith(baseDir));
• advertises content types by file extension (text/javascript, text/css, …).

The public API of WebviewAssetServer (resolve, getUri, stop), the ContextHandler, context path /, and the 127.0.0.1 virtual-host restriction are all unchanged, so ChatWebViewAssetProvider and ToolkitLoginWebViewAssetProvider need no changes.

org.eclipse.jetty.http (already a transitive dependency of org.eclipse.jetty.server) is added to Require-Bundle for HttpHeader / HttpStatus.

Testing

Added WebviewAssetServerTest (JUnit 5):

• getContentType resolution (known extensions, case-insensitivity, unknown / missing extension fallback);
• HTTP round-trip against the started server: serves a JS asset with the correct content type, serves a nested asset, and returns 404 for a missing asset.

Verified locally against the real Jetty 12.0.9 API (the version the plugin builds against):

• javac -Xlint:all compiles cleanly;
• all 5 tests pass;
• Checkstyle (10.23.1, plugin/checkstyle.xml) reports no violations.

Note: I was unable to run the full mvn package Tycho build in my environment; the GitHub Actions sanity build will exercise it on this PR. The fix itself addresses a Windows-only code path; the regression test runs on all platforms and confirms the new serving mechanism works.

[laileni-aws]

Problem

Closes#560.

On Eclipse 2026-06 (4.40.0) the Amazon Q chat (and login) view renders as a blank screen. The webview asset server throws:

java.nio.file.InvalidPathException: Invalid PathInContext: /amazonq-ui.js
...
Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 2:
/C:/Users/<user>/eclipse-workspace/.metadata/.plugins/amazon-q-eclipse/lsp/AmazonQAgentic/1.70.0/clients/amazonq-ui.js
at java.base/sun.nio.fs.WindowsPathParser.normalize(...)
at java.base/java.nio.file.Path.resolve(Path.java:516)
at org.eclipse.jetty.util.resource.PathResource.resolveSchemeSpecificPath(PathResource.java:315)
at org.eclipse.jetty.util.resource.PathResource.resolve(PathResource.java:296)

Root cause

WebviewAssetServer served the LSP-provided UI directory through Jetty's ResourceHandler + setBaseResource(<dir>). To serve a request such as GET /amazonq-ui.js, Jetty resolves the request path against the base resource via PathResource#resolve.

The Jetty version the plugin builds against (12.0.9, Eclipse 2024-06) implemented this with Paths.get(resolvedUri), which correctly handles a Windows file:///C:/... URI. The newer Jetty bundled with Eclipse 4.40.0 changed PathResource#resolve to delegate to resolveSchemeSpecificPath(...), which combines the request into a URI-style string (/C:/Users/.../amazonq-ui.js) and passes it to Path#resolve(String). On Windows that string is rejected — : is illegal at index 2 because of the leading / before the drive letter — so no asset is ever served and the webview stays blank.

Because the broken code lives in the Jetty bundle supplied by the Eclipse target platform, we can't fix it there; the plugin must stop relying on PathResource#resolve.

Fix

Replace the ResourceHandler with a small Handler.Abstract (StaticFileHandler) that serves files from the asset directory using java.nio:

• resolves the request path relative to the base directory (baseDir.resolve(relativePath)), so the resulting path never contains a leading-slash + drive-letter sequence and stays valid on every platform;
• keeps a path-traversal guard (resolved.startsWith(baseDir));
• advertises content types by file extension (text/javascript, text/css, …).

The public API of WebviewAssetServer (resolve, getUri, stop), the ContextHandler, context path /, and the 127.0.0.1 virtual-host restriction are all unchanged, so ChatWebViewAssetProvider and ToolkitLoginWebViewAssetProvider need no changes.

org.eclipse.jetty.http (already a transitive dependency of org.eclipse.jetty.server) is added to Require-Bundle for HttpHeader / HttpStatus.

Testing

Added WebviewAssetServerTest (JUnit 5):

• getContentType resolution (known extensions, case-insensitivity, unknown / missing extension fallback);
• HTTP round-trip against the started server: serves a JS asset with the correct content type, serves a nested asset, and returns 404 for a missing asset.

Verified locally against the real Jetty 12.0.9 API (the version the plugin builds against):

• javac -Xlint:all compiles cleanly;
• all 5 tests pass;
• Checkstyle (10.23.1, plugin/checkstyle.xml) reports no violations.

Note: I was unable to run the full mvn package Tycho build in my environment; the GitHub Actions sanity build will exercise it on this PR. The fix itself addresses a Windows-only code path; the regression test runs on all platforms and confirms the new serving mechanism works.

[laileni-aws]

Problem

Closes#560.

On Eclipse 2026-06 (4.40.0) the Amazon Q chat (and login) view renders as a blank screen. The webview asset server throws:

java.nio.file.InvalidPathException: Invalid PathInContext: /amazonq-ui.js
...
Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 2:
/C:/Users/<user>/eclipse-workspace/.metadata/.plugins/amazon-q-eclipse/lsp/AmazonQAgentic/1.70.0/clients/amazonq-ui.js
at java.base/sun.nio.fs.WindowsPathParser.normalize(...)
at java.base/java.nio.file.Path.resolve(Path.java:516)
at org.eclipse.jetty.util.resource.PathResource.resolveSchemeSpecificPath(PathResource.java:315)
at org.eclipse.jetty.util.resource.PathResource.resolve(PathResource.java:296)

Root cause

WebviewAssetServer served the LSP-provided UI directory through Jetty's ResourceHandler + setBaseResource(<dir>). To serve a request such as GET /amazonq-ui.js, Jetty resolves the request path against the base resource via PathResource#resolve.

The Jetty version the plugin builds against (12.0.9, Eclipse 2024-06) implemented this with Paths.get(resolvedUri), which correctly handles a Windows file:///C:/... URI. The newer Jetty bundled with Eclipse 4.40.0 changed PathResource#resolve to delegate to resolveSchemeSpecificPath(...), which combines the request into a URI-style string (/C:/Users/.../amazonq-ui.js) and passes it to Path#resolve(String). On Windows that string is rejected — : is illegal at index 2 because of the leading / before the drive letter — so no asset is ever served and the webview stays blank.

Because the broken code lives in the Jetty bundle supplied by the Eclipse target platform, we can't fix it there; the plugin must stop relying on PathResource#resolve.

Fix

Replace the ResourceHandler with a small Handler.Abstract (StaticFileHandler) that serves files from the asset directory using java.nio:

• resolves the request path relative to the base directory (baseDir.resolve(relativePath)), so the resulting path never contains a leading-slash + drive-letter sequence and stays valid on every platform;
• keeps a path-traversal guard (resolved.startsWith(baseDir));
• advertises content types by file extension (text/javascript, text/css, …).

The public API of WebviewAssetServer (resolve, getUri, stop), the ContextHandler, context path /, and the 127.0.0.1 virtual-host restriction are all unchanged, so ChatWebViewAssetProvider and ToolkitLoginWebViewAssetProvider need no changes.

org.eclipse.jetty.http (already a transitive dependency of org.eclipse.jetty.server) is added to Require-Bundle for HttpHeader / HttpStatus.

Testing

Added WebviewAssetServerTest (JUnit 5):

• getContentType resolution (known extensions, case-insensitivity, unknown / missing extension fallback);
• HTTP round-trip against the started server: serves a JS asset with the correct content type, serves a nested asset, and returns 404 for a missing asset.

Verified locally against the real Jetty 12.0.9 API (the version the plugin builds against):

• javac -Xlint:all compiles cleanly;
• all 5 tests pass;
• Checkstyle (10.23.1, plugin/checkstyle.xml) reports no violations.

Note: I was unable to run the full mvn package Tycho build in my environment; the GitHub Actions sanity build will exercise it on this PR. The fix itself addresses a Windows-only code path; the regression test runs on all platforms and confirms the new serving mechanism works.

[laileni-aws]

Problem

Closes#560.

On Eclipse 2026-06 (4.40.0) the Amazon Q chat (and login) view renders as a blank screen. The webview asset server throws:

java.nio.file.InvalidPathException: Invalid PathInContext: /amazonq-ui.js
...
Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 2:
/C:/Users/<user>/eclipse-workspace/.metadata/.plugins/amazon-q-eclipse/lsp/AmazonQAgentic/1.70.0/clients/amazonq-ui.js
at java.base/sun.nio.fs.WindowsPathParser.normalize(...)
at java.base/java.nio.file.Path.resolve(Path.java:516)
at org.eclipse.jetty.util.resource.PathResource.resolveSchemeSpecificPath(PathResource.java:315)
at org.eclipse.jetty.util.resource.PathResource.resolve(PathResource.java:296)

Root cause

WebviewAssetServer served the LSP-provided UI directory through Jetty's ResourceHandler + setBaseResource(<dir>). To serve a request such as GET /amazonq-ui.js, Jetty resolves the request path against the base resource via PathResource#resolve.

The Jetty version the plugin builds against (12.0.9, Eclipse 2024-06) implemented this with Paths.get(resolvedUri), which correctly handles a Windows file:///C:/... URI. The newer Jetty bundled with Eclipse 4.40.0 changed PathResource#resolve to delegate to resolveSchemeSpecificPath(...), which combines the request into a URI-style string (/C:/Users/.../amazonq-ui.js) and passes it to Path#resolve(String). On Windows that string is rejected — : is illegal at index 2 because of the leading / before the drive letter — so no asset is ever served and the webview stays blank.

Because the broken code lives in the Jetty bundle supplied by the Eclipse target platform, we can't fix it there; the plugin must stop relying on PathResource#resolve.

Fix

Replace the ResourceHandler with a small Handler.Abstract (StaticFileHandler) that serves files from the asset directory using java.nio:

• resolves the request path relative to the base directory (baseDir.resolve(relativePath)), so the resulting path never contains a leading-slash + drive-letter sequence and stays valid on every platform;
• keeps a path-traversal guard (resolved.startsWith(baseDir));
• advertises content types by file extension (text/javascript, text/css, …).

The public API of WebviewAssetServer (resolve, getUri, stop), the ContextHandler, context path /, and the 127.0.0.1 virtual-host restriction are all unchanged, so ChatWebViewAssetProvider and ToolkitLoginWebViewAssetProvider need no changes.

org.eclipse.jetty.http (already a transitive dependency of org.eclipse.jetty.server) is added to Require-Bundle for HttpHeader / HttpStatus.

Testing

Added WebviewAssetServerTest (JUnit 5):

• getContentType resolution (known extensions, case-insensitivity, unknown / missing extension fallback);
• HTTP round-trip against the started server: serves a JS asset with the correct content type, serves a nested asset, and returns 404 for a missing asset.

Verified locally against the real Jetty 12.0.9 API (the version the plugin builds against):

• javac -Xlint:all compiles cleanly;
• all 5 tests pass;
• Checkstyle (10.23.1, plugin/checkstyle.xml) reports no violations.

Note: I was unable to run the full mvn package Tycho build in my environment; the GitHub Actions sanity build will exercise it on this PR. The fix itself addresses a Windows-only code path; the regression test runs on all platforms and confirms the new serving mechanism works.

[laileni-aws]

Problem

Closes#560.

On Eclipse 2026-06 (4.40.0) the Amazon Q chat (and login) view renders as a blank screen. The webview asset server throws:

java.nio.file.InvalidPathException: Invalid PathInContext: /amazonq-ui.js
...
Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 2:
/C:/Users/<user>/eclipse-workspace/.metadata/.plugins/amazon-q-eclipse/lsp/AmazonQAgentic/1.70.0/clients/amazonq-ui.js
at java.base/sun.nio.fs.WindowsPathParser.normalize(...)
at java.base/java.nio.file.Path.resolve(Path.java:516)
at org.eclipse.jetty.util.resource.PathResource.resolveSchemeSpecificPath(PathResource.java:315)
at org.eclipse.jetty.util.resource.PathResource.resolve(PathResource.java:296)

Root cause

WebviewAssetServer served the LSP-provided UI directory through Jetty's ResourceHandler + setBaseResource(<dir>). To serve a request such as GET /amazonq-ui.js, Jetty resolves the request path against the base resource via PathResource#resolve.

The Jetty version the plugin builds against (12.0.9, Eclipse 2024-06) implemented this with Paths.get(resolvedUri), which correctly handles a Windows file:///C:/... URI. The newer Jetty bundled with Eclipse 4.40.0 changed PathResource#resolve to delegate to resolveSchemeSpecificPath(...), which combines the request into a URI-style string (/C:/Users/.../amazonq-ui.js) and passes it to Path#resolve(String). On Windows that string is rejected — : is illegal at index 2 because of the leading / before the drive letter — so no asset is ever served and the webview stays blank.

Because the broken code lives in the Jetty bundle supplied by the Eclipse target platform, we can't fix it there; the plugin must stop relying on PathResource#resolve.

Fix

Replace the ResourceHandler with a small Handler.Abstract (StaticFileHandler) that serves files from the asset directory using java.nio:

• resolves the request path relative to the base directory (baseDir.resolve(relativePath)), so the resulting path never contains a leading-slash + drive-letter sequence and stays valid on every platform;
• keeps a path-traversal guard (resolved.startsWith(baseDir));
• advertises content types by file extension (text/javascript, text/css, …).

The public API of WebviewAssetServer (resolve, getUri, stop), the ContextHandler, context path /, and the 127.0.0.1 virtual-host restriction are all unchanged, so ChatWebViewAssetProvider and ToolkitLoginWebViewAssetProvider need no changes.

org.eclipse.jetty.http (already a transitive dependency of org.eclipse.jetty.server) is added to Require-Bundle for HttpHeader / HttpStatus.

Testing

Added WebviewAssetServerTest (JUnit 5):

• getContentType resolution (known extensions, case-insensitivity, unknown / missing extension fallback);
• HTTP round-trip against the started server: serves a JS asset with the correct content type, serves a nested asset, and returns 404 for a missing asset.

Verified locally against the real Jetty 12.0.9 API (the version the plugin builds against):

• javac -Xlint:all compiles cleanly;
• all 5 tests pass;
• Checkstyle (10.23.1, plugin/checkstyle.xml) reports no violations.

Note: I was unable to run the full mvn package Tycho build in my environment; the GitHub Actions sanity build will exercise it on this PR. The fix itself addresses a Windows-only code path; the regression test runs on all platforms and confirms the new serving mechanism works.

[laileni-aws]

Problem

Closes#560.

On Eclipse 2026-06 (4.40.0) the Amazon Q chat (and login) view renders as a blank screen. The webview asset server throws:

java.nio.file.InvalidPathException: Invalid PathInContext: /amazonq-ui.js
...
Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 2:
/C:/Users/<user>/eclipse-workspace/.metadata/.plugins/amazon-q-eclipse/lsp/AmazonQAgentic/1.70.0/clients/amazonq-ui.js
at java.base/sun.nio.fs.WindowsPathParser.normalize(...)
at java.base/java.nio.file.Path.resolve(Path.java:516)
at org.eclipse.jetty.util.resource.PathResource.resolveSchemeSpecificPath(PathResource.java:315)
at org.eclipse.jetty.util.resource.PathResource.resolve(PathResource.java:296)

Root cause

WebviewAssetServer served the LSP-provided UI directory through Jetty's ResourceHandler + setBaseResource(<dir>). To serve a request such as GET /amazonq-ui.js, Jetty resolves the request path against the base resource via PathResource#resolve.

The Jetty version the plugin builds against (12.0.9, Eclipse 2024-06) implemented this with Paths.get(resolvedUri), which correctly handles a Windows file:///C:/... URI. The newer Jetty bundled with Eclipse 4.40.0 changed PathResource#resolve to delegate to resolveSchemeSpecificPath(...), which combines the request into a URI-style string (/C:/Users/.../amazonq-ui.js) and passes it to Path#resolve(String). On Windows that string is rejected — : is illegal at index 2 because of the leading / before the drive letter — so no asset is ever served and the webview stays blank.

Because the broken code lives in the Jetty bundle supplied by the Eclipse target platform, we can't fix it there; the plugin must stop relying on PathResource#resolve.

Fix

Replace the ResourceHandler with a small Handler.Abstract (StaticFileHandler) that serves files from the asset directory using java.nio:

• resolves the request path relative to the base directory (baseDir.resolve(relativePath)), so the resulting path never contains a leading-slash + drive-letter sequence and stays valid on every platform;
• keeps a path-traversal guard (resolved.startsWith(baseDir));
• advertises content types by file extension (text/javascript, text/css, …).

The public API of WebviewAssetServer (resolve, getUri, stop), the ContextHandler, context path /, and the 127.0.0.1 virtual-host restriction are all unchanged, so ChatWebViewAssetProvider and ToolkitLoginWebViewAssetProvider need no changes.

org.eclipse.jetty.http (already a transitive dependency of org.eclipse.jetty.server) is added to Require-Bundle for HttpHeader / HttpStatus.

Testing

Added WebviewAssetServerTest (JUnit 5):

• getContentType resolution (known extensions, case-insensitivity, unknown / missing extension fallback);
• HTTP round-trip against the started server: serves a JS asset with the correct content type, serves a nested asset, and returns 404 for a missing asset.

Verified locally against the real Jetty 12.0.9 API (the version the plugin builds against):

• javac -Xlint:all compiles cleanly;
• all 5 tests pass;
• Checkstyle (10.23.1, plugin/checkstyle.xml) reports no violations.

Note: I was unable to run the full mvn package Tycho build in my environment; the GitHub Actions sanity build will exercise it on this PR. The fix itself addresses a Windows-only code path; the regression test runs on all platforms and confirms the new serving mechanism works.

[laileni-aws]

Problem

Closes#560.

On Eclipse 2026-06 (4.40.0) the Amazon Q chat (and login) view renders as a blank screen. The webview asset server throws:

java.nio.file.InvalidPathException: Invalid PathInContext: /amazonq-ui.js
...
Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 2:
/C:/Users/<user>/eclipse-workspace/.metadata/.plugins/amazon-q-eclipse/lsp/AmazonQAgentic/1.70.0/clients/amazonq-ui.js
at java.base/sun.nio.fs.WindowsPathParser.normalize(...)
at java.base/java.nio.file.Path.resolve(Path.java:516)
at org.eclipse.jetty.util.resource.PathResource.resolveSchemeSpecificPath(PathResource.java:315)
at org.eclipse.jetty.util.resource.PathResource.resolve(PathResource.java:296)

Root cause

WebviewAssetServer served the LSP-provided UI directory through Jetty's ResourceHandler + setBaseResource(<dir>). To serve a request such as GET /amazonq-ui.js, Jetty resolves the request path against the base resource via PathResource#resolve.

The Jetty version the plugin builds against (12.0.9, Eclipse 2024-06) implemented this with Paths.get(resolvedUri), which correctly handles a Windows file:///C:/... URI. The newer Jetty bundled with Eclipse 4.40.0 changed PathResource#resolve to delegate to resolveSchemeSpecificPath(...), which combines the request into a URI-style string (/C:/Users/.../amazonq-ui.js) and passes it to Path#resolve(String). On Windows that string is rejected — : is illegal at index 2 because of the leading / before the drive letter — so no asset is ever served and the webview stays blank.

Because the broken code lives in the Jetty bundle supplied by the Eclipse target platform, we can't fix it there; the plugin must stop relying on PathResource#resolve.

Fix

Replace the ResourceHandler with a small Handler.Abstract (StaticFileHandler) that serves files from the asset directory using java.nio:

• resolves the request path relative to the base directory (baseDir.resolve(relativePath)), so the resulting path never contains a leading-slash + drive-letter sequence and stays valid on every platform;
• keeps a path-traversal guard (resolved.startsWith(baseDir));
• advertises content types by file extension (text/javascript, text/css, …).

The public API of WebviewAssetServer (resolve, getUri, stop), the ContextHandler, context path /, and the 127.0.0.1 virtual-host restriction are all unchanged, so ChatWebViewAssetProvider and ToolkitLoginWebViewAssetProvider need no changes.

org.eclipse.jetty.http (already a transitive dependency of org.eclipse.jetty.server) is added to Require-Bundle for HttpHeader / HttpStatus.

Testing

Added WebviewAssetServerTest (JUnit 5):

• getContentType resolution (known extensions, case-insensitivity, unknown / missing extension fallback);
• HTTP round-trip against the started server: serves a JS asset with the correct content type, serves a nested asset, and returns 404 for a missing asset.

Verified locally against the real Jetty 12.0.9 API (the version the plugin builds against):

• javac -Xlint:all compiles cleanly;
• all 5 tests pass;
• Checkstyle (10.23.1, plugin/checkstyle.xml) reports no violations.

Note: I was unable to run the full mvn package Tycho build in my environment; the GitHub Actions sanity build will exercise it on this PR. The fix itself addresses a Windows-only code path; the regression test runs on all platforms and confirms the new serving mechanism works.