Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jetty 12 fails to start WebApp Bundle with OSGi Boot bundle (or when packaged) #11377

Closed
cmark opened this issue Feb 6, 2024 · 14 comments · Fixed by #11418
Closed

Jetty 12 fails to start WebApp Bundle with OSGi Boot bundle (or when packaged) #11377

cmark opened this issue Feb 6, 2024 · 14 comments · Fixed by #11418
Assignees
Labels
Bug For general bugs on Jetty side

Comments

@cmark
Copy link

cmark commented Feb 6, 2024

Jetty version(s)
Jetty 12.0.6

Jetty Environment
ee10

Java version/vendor (use: java -version)
openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment Temurin-17.0.10+7 (build 17.0.10+7)
OpenJDK 64-Bit Server VM Temurin-17.0.10+7 (build 17.0.10+7, mixed mode, sharing)

OS type/version
Microsoft Windows 10 22H2 (OS Build 19045.3930)

Description

Thank you for fixing the osgi.boot bundle config errors (#11280) and releasing it as part of 12.0.6.
Unfortunately, we are still unable to our tests and our runtime due to an invalid path exception error.

Local dev env error when starting our test launch configuration from Eclipse:

[2024-02-06T10:55:39.028] WARN  main                                             org.eclipse.jetty.deploy.DeploymentManager                       Unable to reach node goal: started java.nio.file.InvalidPathException: Illegal char <:> at index 4: file:///C:/jettyhome
	at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
	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:232)
	at java.base/java.nio.file.Path.of(Path.java:147)
	at java.base/java.nio.file.Paths.get(Paths.java:69)
	at org.eclipse.jetty.ee10.osgi.boot.EE10Activator$EE10WebAppFactory.createContextHandler(EE10Activator.java:360)

We are configuring the osgi.boot bundle using the jetty.home.bundle jvm argument:

-Djetty.home.bundle=org.eclipse.jetty.ee10.osgi.boot

The error is similar in our build regardless of whether we use the osgi.boot bundle or using custom jetty*.xml configuration:

[2024-02-06T11:17:10.632] WARN  main                                             org.eclipse.jetty.ee10.webapp.WebAppContext                      Failed startup of context oeje10w.WebAppContext@7e461408{/snowowl,/snowowl,b=null,a=STOPPED,h=oeje10s.SessionHandler@7d86a2fd{STOPPED}}{file:/C:/dev/snow-owl-9.x/git/snow-owl/core/com.b2international.snowowl.core.rest/target/com.b2international.snowowl.core.rest-9.0.1-SNAPSHOT.jar} java.nio.file.InvalidPathException: Illegal char <:> at index 4: file:/C:/dev/snow-owl-9.x/git/snow-owl/core/com.b2international.snowowl.core.rest/target/com.b2international.snowowl.core.rest-9.0.1-SNAPSHOT.jar
	at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
	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:232)
	at java.base/java.nio.file.Path.of(Path.java:147)
	at org.eclipse.jetty.ee10.webapp.WebInfConfiguration.unpack(WebInfConfiguration.java:242)
	at org.eclipse.jetty.ee10.webapp.WebInfConfiguration.preConfigure(WebInfConfiguration.java:66)
	at org.eclipse.jetty.ee10.webapp.Configurations.preConfigure(Configurations.java:487)
	at org.eclipse.jetty.ee10.webapp.WebAppContext.preConfigure(WebAppContext.java:454)
	at org.eclipse.jetty.ee10.webapp.WebAppContext.doStart(WebAppContext.java:495)
	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)

Our web app bundle should boot based on a WEB-INF/web.xml file, but it looks like there is a preConfigure step that runs for every recognized configuration class and if one of them fails then the boot process fails.
While this is a warning, there is no other error that can be found in the logs regarding the boot process and everything seems to work if we use explicit jetty.xml configuration files and not embedded ones (or the boot bundle).

Could this be a configuration issue on our end?

How to reproduce?

@cmark cmark added the Bug For general bugs on Jetty side label Feb 6, 2024
cmark added a commit to b2ihealthcare/snow-owl that referenced this issue Feb 6, 2024
@cmark
Copy link
Author

cmark commented Feb 6, 2024

It looks like our packaged runtime is also failing with a similar error when it tries to boot the webapp bundle. Just guessing, but I think the cause is related to the fact that this is not a war but a jar and the WebInfConfiguration fails to detect that in the preConfigure step for an unknown reason. When running the dev version locally where the webapp bundle is not packaged yet (imported as an Eclipse project) the deployment works without any issue, but packaging it into an OSGi Web App and trying to deploy it fails.

@cmark cmark changed the title Jetty 12 fails to start WebApp Bundle with OSGi Boot bundle (or with embedded jetty.xml files) Jetty 12 fails to start WebApp Bundle with OSGi Boot bundle (or ~with embedded jetty.xml files~ when packaged) Feb 6, 2024
@cmark cmark changed the title Jetty 12 fails to start WebApp Bundle with OSGi Boot bundle (or ~with embedded jetty.xml files~ when packaged) Jetty 12 fails to start WebApp Bundle with OSGi Boot bundle (or when packaged) Feb 6, 2024
@janbartel
Copy link
Contributor

The jetty code base changed from using the Resource class to resolve locations to using the jvm Path class instead. Resource was very flexible with the way it resolved locations, it could handle URI or just a file location, but Path is more finicky.. Can you try just passing in the location as C:/jettyhome?

@cmark
Copy link
Author

cmark commented Feb 7, 2024

I can try but that can only work around the osgi.boot related issue.
The other is about accessing and extracting the contents of the webapp jar file which fails because the URI starts with file:/. It looks like it does some conversion to jar:/ but the code uses the war location path, which is still a file:/ and that does not work with jvm Path.

Correct me if I'm wrong, but shouldn't the code in this block alter the value of the war variable? It seems like that even if jvm Path would resolve the location without errors to a Path object unpack would not happen because the webapp is not a war file.

@cmark
Copy link
Author

cmark commented Feb 7, 2024

Can you try just passing in the location as C:/jettyhome?

Setting both the jetty.home.bundle and jetty.home together won't work as the system will ignore the jetty.home.bundle altogether.

[2024-02-07T10:19:00.360] WARN  main    org.eclipse.jetty.osgi.JettyBootstrapActivator                   Both jetty.home and jetty.home.bundle property defined: jetty.home.bundle ignored. 
[2024-02-07T10:19:00.360] WARN  main    org.eclipse.jetty.osgi.JettyBootstrapActivator                   Unable to locate the jetty.home folder C:/jettyhome 

We need the osgi.boot bundle to boot up the jetty context with defaults in OSGi context and also to recognize and boot our webapp bundle.

According to my understanding, the C:/jettyhome path is a fake path generated/set by the osgi.boot bundle during init, at least that was the case with Jetty 9 and 10.

@cmark
Copy link
Author

cmark commented Feb 7, 2024

After a bit of further testing, it looks like Jetty 12 and the web app can successfully boot on Unix machines without any Path issues. So this could be only affecting deployments on Windows machines.

@janbartel
Copy link
Contributor

@cmark yeah, I think the change to Path is our issue here, I'll work on a PR to fix it.

@janbartel
Copy link
Contributor

@cmark you might like to build and test the PR #11418 in your environment and see if I've fixed it?

@cmark
Copy link
Author

cmark commented Feb 19, 2024

@cmark you might like to build and test the PR #11418 in your environment and see if I've fixed it?

Hey, I can take a look. I'll let you know if the issue is still present or not. Thanks!

@cmark
Copy link
Author

cmark commented Feb 23, 2024

@janbartel

Fixes in #11418 do resolve the osgi.boot path issue when running our integration tests on a developer machine with Windows 10. With that we can start using the osgi.boot bundle again in our tests. ☺️

Unfortunately, the other error thrown at org.eclipse.jetty.ee10.webapp.WebInfConfiguration.unpack(WebInfConfiguration.java:242) is still present if we build our modules on Windows via Maven.

@janbartel
Copy link
Contributor

Thans @cmark I'll take a look at the WebInfConfiguration issue.

@janbartel
Copy link
Contributor

@joakime as you're looking into windows issues, can you also look at the Exception generated when performing a WebInfConfiguration.unpack on windows with a url like file:/C:/xxx/yyy/zzz.jar (Note, the .jar could be a .war also).

The OP here has the full stack trace: #11377 (comment)

@janbartel
Copy link
Contributor

@cmark I've pushed a speculative fix for WebInfConfiguration.unpack to that branch, any chance you could retest??

@cmark
Copy link
Author

cmark commented Feb 23, 2024

@cmark I've pushed a speculative fix for WebInfConfiguration.unpack to that branch, any chance you could retest??

Yeah sure, I will rebuild and retest now.

@cmark
Copy link
Author

cmark commented Feb 23, 2024

@janbartel I'm happy to report that the speculative fix resolves the other error. Nice! Thanks!

janbartel added a commit that referenced this issue Feb 26, 2024
* Issue #11377 fix jettyhome osgi path and  WebInfConfiguration.unpack for windows
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For general bugs on Jetty side
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants