-
|
I started a new jetty-base with http, using jakarta ee11 with servlet-api-6.1.0, and copied my jetty10 webapps dir in. I'm stuck on ClassNotFoundException: org.eclipse.jetty.webapp.WebAppContext. It sounds like something that a web search should solve, and if so I'd sure like to know the query that works. As a dev, it looks like a potential place to put a more explicit error message. [Unless my redefined logging setup misses some layer's logging? It's all going to nohup.out so far, minor issue.] war is pr.war It seems that WebAppContext was coming from webapps/.xml before. Now I've 12.1.7/ee11'd it, or so I thought: If I take out the .ee11. in the class name, the Exception looks like this: General setup: |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 4 replies
-
|
I also upgraded gradle and gretty, and have this in build.gradle for the .war: And web.xml updated: Here's the works-with-jetty10 base: https://github.com/phobrain/Phobrain/tree/main/pr/jetty-base Making the web-app version=6.1.0 [adding .0] and keeping .ee11. in the class name I just got further? But what "1.0" can't be parsed? The only "1.0" I find in config files is the xml version, which has to be that. |
Beta Was this translation helpful? Give feedback.
-
That's invalid for Jakarta Servlet 6.1 Here, use this ... <?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_6_1.xsd"
version="6.1">Unfortunately, the official spec document has a broken example for this heading. A bug has been filed for that broken spec document. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! With "6.1.0" the objection to "1.0" also remains - which I now suspect is due to the added ".0" i.e. red herring that could also explain itself better [based on decades of code support]: Could it be similar newness is needed in the jetty-base/webapps/pr.xml file (shown above), given the WebAppContext is defined there? E.g. is configure_12_1_7.dtd correct? Alternative: my app isn't logging, and that's what needs fixing next. If so, the missing context error might point the finger at logs from the app itself, rather than ClassNotFoundException. Alternative: am I screening the class from the .war with this: I also tried with Looking at logging, I see the only logback jar is in ~/.gradle/, and in porting the web server build.gradle, I changed it to runtimeOnly: Where before I had a jar in jetty-base: So I was expecting to have to add one at some point. And in jetty-base/resources/jetty-logging.properties I had which doesn't seem to change anything when added to the new one. NB: I have nothing invested in logback if there's a more-standard approach. Unpacking pr.war, I see it has WebAppContext, and logback jars: |
Beta Was this translation helpful? Give feedback.
-
That classname is
This occurs during the XML document element parsing, which is the opening XML declaration (the See:
The DTD reference is still The version you see there is a DTD version, not really tied to a Jetty version, in the past it seemed like it was Jetty specific, but that was just a coincidence. Example:
That line wasn't necessary in Jetty 10 either. Use one of the logging implementation provided by jetty-home / jetty-start. Example ... Note: the |
Beta Was this translation helpful? Give feedback.
-
|
Logging setup is amazing since the last time I struggled with it. Is logging-jetty necessary/irrelevant/wrong with logging-logback? The description makes it sound required, but your example leaves it out. logging-jcl-capture seems like a no-brainer with jakarta and slf4j - any reason why not? console-capture sounds like a great rolling alternative to my growing nohup.out file. Is logging/slf4j irrelevant (as well as different format) in a new setup? "logging/slf4j - Configures logging to use SLF4J." Current setup script |
Beta Was this translation helpful? Give feedback.
-
|
It works. Summary including advice since initial liftoff:
|
Beta Was this translation helpful? Give feedback.
-
|
The DTD for Jetty XML is Please restore that the reference to the DTD to be |
Beta Was this translation helpful? Give feedback.
It works. Summary including advice since initial liftoff:
Converted jetty-env.xml (db connection info, forgotten file) to jetty-ee11-env.xml.
Config dtd version is "https://jetty.org/configure_10_0.dtd", don't copy the jetty release version number [sbordet]
web.xml header in docs was wrong, bug filed. See Joakim's first response for correct one, includes web-app_6_1.xsd.
Logging: scope it out via "$ java -jar jetty-home-12.1.7/start.jar --list-modules=logging" and see Joakim's logback example above.
war: excluded file names containing webapp and jakarta from the war build to avoid issues with having the same ones from different class loaders.