Announcement

**Isomorphic** · 30 May 2025, 13:11

We think what's going on is that Jetty 12.0 is naively passing fmt:bundle into Paths.get() without sanitization, then if you are on Windows, "fmt:" looks like an invalid drive letter.

A workaround would be to use:

Code:

     xmlns:fmt="/WEB-INF/"

.. because the leading slash should have no effect on resource lookups, but will work around Jetty's behavior here.

Please let us know if that solves the problem and your i18n resources still load.

**aderosso** · 2 Jun 2025, 09:07

I tried that change, I still get the same error:

Code:

Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 73: .../titan-server/src/main/webapp/titan/sc/system/schema/fmt:bundle.ds.xml
    at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:204) ~[?:?]
    at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:175) ~[?:?]
    at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) ~[?:?]
    at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) ~[?:?]
    at java.base/sun.nio.fs.WindowsUriSupport.fromUri(WindowsUriSupport.java:166) ~[?:?]
    at java.base/sun.nio.fs.WindowsFileSystemProvider.getPath(WindowsFileSystemProvider.java:96) ~[?:?]
    at java.base/java.nio.file.Path.of(Path.java:204) ~[?:?]
    at java.base/java.nio.file.Paths.get(Paths.java:98) ~[?:?]

**Isomorphic** · 2 Jun 2025, 10:13

OK, to explain what's happening: SmartGWT's .ds.xml engine encounters the <fmt:bundle> XML tag and looks for a schema file for that tag, which would have the name "fmt:bundle.ds.xml".

Even though we're calling ServletContext.getResource(), this causes Jetty to checks the actual filesystem, presumably because you are running in "exploded war" mode or similar.

At that point Windows (or really the Java code that is about to call native Windows APIs) throws an exception, because ":" is an illegal character in Windows file names, even if the drive letter is already unambiguously specified at the beginning of the path.

It's too bad it throws an Exception instead of just indicating there is no such file, especially when the caller is getResource() (!!!!). That makes this is a Jetty bug, because JAR paths are not restricted to Windows-valid chars, so getResource() should not be blowing up - that effectively means you can't put anything in a .jar that doesn't follow Windows' filename conventions!

But oh well, we'll have to work around it: we'll specify that schema IDs cannot have characters that are disallowed in Windows file names, and put in a backcompat release note and backcompat flag for people who don't care about Windows.

We should have this in place within a couple of days. In the meantime, if you're blocked, you may be able to put Jetty in a mode where getResource() does not try to hit the filesystem, and only looks in .jars.

ChatGPT tells us this is not possible via Jetty settings but may be possible like so (context is the servletContext). We haven't tested this and it could be a hallucination:

Code:

context.setBaseResource(Resource.newClassPathResource("/webapp"));

**aderosso** · 2 Jun 2025, 11:11

I don't see that method in ServletContext. We're blocked in an upgrade to Jetty 12, but that's not something that has to happen on a timeline. We can wait for the change, thank you!

**Isomorphic** · 2 Jun 2025, 11:23

Sounds good.

Just for background it's this API:

https://docs.oracle.com/cd/E17802_01...va.lang.String)

.. and it's how you get the resources that were deployed (in .jars) with your app, in deployments where you are not allowed to access the filesystem.

**Isomorphic** · 3 Jun 2025, 13:45

This should be fixed now, in 14.1 and 15.0 builds as of tomorrow, June 4th. Please try your case with a new build and let us know, thanks.

**aderosso** · 4 Jun 2025, 09:19

That worked! Thank you very much for the quick fix

Announcement

Jetty 12 Error

Comment

Comment

Comment

Comment

Comment

Comment

Comment