I have created a new jetty-ee8-webapp-12.0.16.jar to get more information.

Under Windows there is an java.nio.file.InvalidPathException:

WARNING: Failed startup of context oeje8w.WebAppContext@1850f359{/test.product,/test.product,null,false}{file:/X:/test-production/test-server/vsrv-test/test.server.test/vsrv/server/test-server-data/org.eclipse.osgi/173/0/bundleFile} [Fri Jan 17 13:40:08 CET 2025]
java.nio.file.InvalidPathException: Illegal char <:> at index 4: file:/X:/test-production/test-server/vsrv-test/test.server.test/vsrv/server/test-server-data/org.eclipse.osgi/173/0/bundleFile
        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.WindowsFileSystem.getPath(WindowsFileSystem.java:231)
        at java.base/java.nio.file.Path.of(Path.java:148)
        at org.eclipse.jetty.ee8.webapp.WebInfConfiguration.unpack(WebInfConfiguration.java:176)
        at org.eclipse.jetty.ee8.webapp.WebInfConfiguration.preConfigure(WebInfConfiguration.java:53)
        at org.eclipse.jetty.ee8.webapp.Configurations.preConfigure(Configurations.java:414)
        at org.eclipse.jetty.ee8.webapp.WebAppContext.preConfigure(WebAppContext.java:470)
        at org.eclipse.jetty.ee8.webapp.WebAppContext.doStart(WebAppContext.java:500)

@joakime the WebInfConfiguration code is doing:

            if (webApp.exists() && (
                (context.isCopyWebDir() && webApp.getPath() != null && originalWarResource.isDirectory()) ||
                    (context.isExtractWAR() && webApp.getPath() != null && !originalWarResource.isDirectory()) ||
                    (context.isExtractWAR() && webApp.getPath() == null) ||
                    !webApp.isDirectory())
            )
            {
                // Look for sibling directory.
                Path extractedWebAppDir = null;

                if (war != null)
                {
                    Path warPath = Path.of(war);
                    // look for a sibling like "foo/" to a "foo.war"
                    if (FileID.isWebArchive(warPath) && Files.exists(warPath))
                    {
                        Path sibling = warPath.getParent().resolve(FileID.getBasename(warPath));
                        if (Files.exists(sibling) && Files.isDirectory(sibling) && Files.isWritable(sibling))
                            extractedWebAppDir = sibling;
                    }
                }

war in this case is the string file:/X:/test-production/test-server/vsrv-test/test.server.test/vsrv/server/test-server-data/org.eclipse.osgi/173/0/bundleFile, which causes the error at the line Path.of(war). I think we can't just expect the war string to be of a useful form as a path. Note that on jetty prior to 12, we did not use Pathin this code, so this was not a problem. Comments?

@joakime I have replaced the line mentioned by @janbartel:

 Path warPath = Path.of(war);

with this line:

 Path warPath = webApp.getPath();

In my case it works on Linux and Windows now.

@janbartel I think the surrounding ìf (war != null) can be deleted

if if (war != null) {
   ....
   Path warPath = webApp.getPath();
   ....
}

@joakime and @janbartel

I correct my self. I more defensive solution would be:

if (war != null)
{
    Path warPath = webApp.getPath();
    if (warPath == null) {
        warPath = Path.of(war);
    }    
   ....

Where did the odd URL of war come from?
That URL appears to be from one of the buggy usages of File.toURL / File.toURI / URL.toURI. (all 3 have known buggy implementations on windows that will never be fixed)

We have a URIUtil.correctURI(URI) specifically to use when using one of those 3 buggy APIs above.

@gpfeifer try using this instead ...

Path warPath = Path.of(URIUtil.correctURI(war));

Hi @joakime

Regarding:

Where did the odd URL of war come from?

I can answer this question in detail if needed. Basically I try to deploy a simple 'Hello World' war in an OSGi container using jetty-osgi. Some details can be found here: https://docs.osgi.org/specification/osgi.enterprise/7.0.0/service.war.html. Basically you need to add the relevant entries to the MANIFEST.MF

Import-Package: javax.servlet;version="[4.0,5)",javax.servlet.annotation ;version="[4.0,5)",javax.servlet.http;version="[4.0,5)",org.eclipse.jetty.ee8.servlets
Jetty-Environment: ee8
Web-ContextPath: /

Of course Jetty-Environment: ee8 is Jetty specific. BTW: I really like that Jetty 12 supports different ee version! Bottom line is: The 'odd URL' is coming from Jetty or OSGi.

I have tried using:

Path warPath = Path.of(URIUtil.correctURI(war))

The variable war is a String. But there is no URIUtil.correctURI method, which accepts a String.

Best regards
Gregor

I have tried using:

Path warPath = Path.of(URIUtil.correctURI(war))

The variable war is a String. But there is no URIUtil.correctURI method, which accepts a String.

Good point.

Can you breakpoint the call ContextHandler.setBaseResource(Resource resourceBase) and see who is setting that?

This line -> https://github.com/jetty/jetty.project/blob/jetty-12.0.16/jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/handler/ContextHandler.java#L1144

Some code is creating the Resource base with the wrong URL/URI, and I want to know who the culprit is, so we can correct it.

Aside: we have to fix WebAppContext.getWar() implementation anyway, as it's using a deprecated method from ee9.ContextHandler.

@joakime Currently I'm not in the position to debug Jetty in my environment. Neither Linux nor Windows. I'm able to add some code (e.g. println) and run it on Windows and Linux. Any suggestions?

@joakime and @janbartel Are you able to reproduce this problem under Windows? Deploying a simple Hello World OSGI War to jetty-osgi under Windows?

@joakime and @janbartel Are you able to reproduce this problem under Windows? Deploying a simple Hello World OSGI War to jetty-osgi under Windows?

Our unit testing of jetty-osgi (all environments) on Windows 10 does not show this issue you are experiencing.

@joakime and @janbartel

It seems that you are using felix in your unit testing. I'm using org.eclipse.osgi (equinoy). Could it be that this issue only occurs when using equinox?

I have analyzed the log (with level debug) and the source code.

In my environment the WebAppContext is created with a Resource.

The instance variable war which is used in

 Path warPath = Path.of(war);

is initialized with:

public void setWarResource(Resource war)
{
    setWar(war == null ? null : war.toString());
}

In my case Resource is a PathResource. Here is the toString method of PathResource:

public String toString()
{
    return this.uri.toASCIIString();
}

In my case the result of 'toString() is 'file:/X:/test-production/....' which is not a valid String to use with Path.of(war).

Could it be that equinox returns something like 'file:/X:/test-production/....' whereas felix would return 'X:/test-production/....' ?

I don't get why we are converting from Resource to String to Path and then back to Resource.

I need to take a closer look at that chain of transformations, I bet we can leave it be as a Resource the entire way through.

I bet we can leave it be as a Resource the entire way through.

Perhaps the instance variable war of WebAppContext should be a Resource instead of a String.....

My problem is: Jetty 10 has a security vulnerability which will not be fixed. It is fixed in Jetty 12. That's why I need to use Jetty 12. My supposed fix for this issue will fix this issue, despite the fact that it is not the best solution. The question is: Can I except a fix within the next 2 month?

"except a fix"?

Did you mean "expect a fix"?

Our release cadence is monthly fixes, this one has low odds of making it for this month, but good odds for next month.

Of course I mean "expect", sorry - a typo. Is there anything I can do to increase the odds?

@joakime @gpfeifer the integration code with the osgi environment is different for the different containers, as they all use very different url mechanisms to represent a bundle. The relevant file is https://github.com/jetty/jetty.project/blob/jetty-12.0.x/jetty-core/jetty-osgi/src/main/java/org/eclipse/jetty/osgi/util/DefaultFileLocatorHelper.java. This code is mostly very old, and has only been tweaked a very small amount. The paths calculated by this code are used by https://github.com/jetty/jetty.project/blob/jetty-12.0.x/jetty-ee9/jetty-ee9-osgi/jetty-ee9-osgi-boot/src/main/java/org/eclipse/jetty/ee9/osgi/boot/EE9Activator.java#L520 to call WebAppContext.setWar(String).

@gpfeifer we use equinox for our testing, with the pax4j osgi testing framework. Are you running on equinox or on felix? We need to try and nail down any differences between your deployment environment and our test environment, because as @joakime says, our tests build on windows.

@janbartel I think the removal of URIUtil.toURI() in commit 9b6944e broke this.

@joakime @janbartel There are a lot of changes regarding URIUtil.toURI(). Can you explain which one(s), so that I can test it on my environment?

I've created PR #12728 which restores the fixing up of file:/ urls on windows. @gpfeifer could you possibly checkout this branch, build it locally and test it to see if it fixes the problem?

@janbartel Unfortunately this does not fix the issue.

My findings so far:

• This Util method is not called in my environment
• The DefaultFileLocatorHelper returns a File constructed with 'zipfile:....' when running your test cases
• The DefaultFileLocatorHelper returns a File constructed with 'zipfile:....' when running in my environment
• In my environment the setWarResource method of WebAppContext is called
• When running your test cases this method is not (!) called

I need to double check all of this findings and will try to find out what is going on here. However: My supposed fix will solve the issue. If there is a Resource available, then ask the Resource for the Path. Another fix would be to change the toString Method of PathResource. Instead of using self.uri simply use self.path.

Thoughts?

@joakime @janbartel Sorry, the last point is wrong. When running your test cases the setWarResource method is called!

Until now I have used Linux to analyze this issue. Today I have build and test this under Windows. Running

mvn test

in jetty-ee9\jetty-ee9-osgi\test-jetty-ee9-osgi yields to the same error (503 - service not available) as in my test environment. e.g.:

[ERROR]   TestJettyOSGiBootWithAnnotations.testIndex:100 Response status code expected:<200> but was:<503>
[ERROR]   TestJettyOSGiBootWithJsp.testJspDump:84 expected:<200> but was:<503>
[ERROR]   TestJettyOSGiClasspathResources.testWebInfResourceNotOnBundleClasspath:94 expected:<200> but was:<503>

Under Linux all tests passed

@joakime @janbartel
This will also fix this issue:

Change this in WebAppContext:

public void setWarResource(Resource war)
{
    setWar(war == null ? null : war.toString());
}

to:

    public void setWarResource(Resource war)
    {
        // We want to be able to construct a Path from the instance variable 'String _war' 
        setWar(war == null ? null : (war.getPath() == null ? null : war.getPath().toString()));
    }

The osgi code that is setting the war string has not really changed. What has changed is the code in WebInfConfiguration that tries to convert the war string directly to a Path. In previous versions of jetty we used it as a Resource and did not have any issues.

I've committed a speculative fix to the PR to change to deriving the Path from the war converted first to a Resource. This may or may not work, but from what I've been able to test (only on Linux) it looks like it has a chance of succeeding.

@gpfeifer could you kindly test again please?

Hi @janbartel

I have take a look at your changes in the PR.

Basically the only change needed to fix the problem is this one (in WebInfConfiguration):

https://github.com/jetty/jetty.project/pull/12728/files#diff-edbd342c37af4b2e5dca9780a8c4028b40475656515f8d57b70fd49aac2aee4e

Remarks:
I think you do not need to create a new Resource:

Resource warResource = context.getResourceFactory().newResource(war);

It is already there. See:

#12723 (comment)

#12723 (comment)

To fix the bug you can choose between this 3 option:

• Use Resource in unpack
• Use getPath instead of toString in setWarResource
• Change toString in PathResource by using the path instead of the uri

Each of them will fix the issue.

But I will test your fix!

Best Regards
Gregor

@gpfeifer you are correct - we have already obtained the webApp as a Resource so we can call getPath() on it directly. I've updated the PR accordingly.

@janbartel @joakime

This PR fixed the issue.

Remarks:

• The change in the unpack method fix the issue. The other changes are not necessary.
• The unpack method of ee9 and ee10 should be harmonized.

@gpfeifer slight change to remove pointless check of war and updated ee10.

Great! Will test it on Monday😊

Hi @janbartel ,
I have tried to build your branch, but it fails with:

  [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.8.1:copy (copy) on project jetty-home: Unable to find/resolve artifact.: The following artifacts could not be resolved: org.eclipse.jetty:jetty-project:txt:version:12.0.17-SNAPSHOT (absent): org.eclipse.jetty:jetty-project:txt:version:12.0.17-SNAPSHOT was not found

Currently I'm busy. Will take a look at this later.

Best regards
Gregor

org.eclipse.jetty:jetty-project:txt:version:12.0.17-SNAPSHOT

Nothing should have a hard dependency on that classified artifact.
This would be a new / different issue, but one that should be fixed.