Undertow warning instead of error if not found

[melloware]

@stuartwdouglas just for safety I think we should change this to a warning because now I am getting 'jakarta.faces` directory does not exist.

Fix #32724

[melloware]

cc @aloubyansky

[stuartwdouglas]

Do you have a reproducer for the other issue? I am ok with this being a warning, but would like to understand the root cause.

[melloware]

Yes my reproducer is the PrimeFaces Extension integration tests they are failing with the nightly 999-SNAPSHOT in Native Mode. See: https://github.com/quarkiverse/quarkus-primefaces/actions/runs/4761639897/jobs/8463084098

Unable to get listed resource jakarta.faces from directory for path from underlying manager io.undertow.server.handlers.resource.ClassPathResourceManager@79802a5dError

[melloware]

Also OmniFaces Extension failing for the same reason: https://github.com/quarkiverse/quarkus-omnifaces/actions/runs/4761634843

[melloware]

@stuartwdouglas @aloubyansky when I run in JVM mode the Integration test passes and here is what gets printed out by the KnownPaths class

Resource: error.xhtml
Resource: favicon.ico
Resource: index.xhtml
Resource: notfound.xhtml
Resource: jakarta.faces
Resource: layout
Resource: omnifaces
Resource: org.apache.myfaces.windowId

But when running in Native mode it fails fast on Resource: jakarta.faces I don't know why.

[melloware]

I would really like to get this merged until we can figure out the real issue as this breaks all JSF related apps using OmniFaces , MyFaces, or PrimeFaces.

[gastaldi]

Can you squash your commits before we merge this?

[melloware]

Squashed!

[quarkus-bot]

✔️ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

[stuartwdouglas]

My guess is that things that are added as known paths in may not be added to the actual native executable, or alternatively it could be that directories are handled differently in native mode and are not showing up.

[stuartwdouglas]

Any chance you could test out #32893 ?

[melloware]

@stuartwdouglas @gastaldi so weird so 3.0.1 just came out and OmniFaces and PrimeFaces builds are passing with it but still failing with the 999-SNAPSHOT overnight build?

[gastaldi]

Try emptying your ~/.m2/repository/io/quarkus and building 999-SNAPSHOT again just in case?

[melloware]

@gastaldi sorry I meant on GitHub Actions. 6 hours ago the EcoSystem CI failed with 999-SNAPSHOT but I just built with 3.0.1 from Dependabot and all tests are passing.

See this: https://github.com/quarkiverse/quarkus-omnifaces/actions

That makes NO sense unless something with the GitHub Actions Maven Cache is messed up on the servers. Like its using an old 999-SNAPSHOT?

[gastaldi]

And can you reproduce the failure building it locally?

[melloware]

Let me try and get set up I use Windows so its not apples to apples with GitHub Actions which was my concern when the overnight EcoSystem CI was failing on Linux.

[melloware]

OK @stuartwdouglas something weird is going on here. If I run the code I posted in the original ticket it doesn't work with 3.0.1.Final.

#28028

quarkus-servlet.zip

1. Unzip the reproducer attached
2. Run mvn clean quarkus:dev and see the servlet paths printed out 2022-12-27 13:00:20,489 INFO [org.acm.ApplicationInitializer] (Quarkus Main Thread) Resource: /index.html
3. Run mvn clean package -DskipTests && java -jar target/quarkus-app/quarkus-run.jar and see the WARNING that no paths found 2022-12-27 13:01:06,297 WARNING [org.acm.ApplicationInitializer] (main) NO servlet resource paths found!

So even in JVM production mode its not finding the /index.html again?

[melloware]

OHHH is it possible none of this code is in 3.0.1 which would explain it and why the nightly build is actually failing.

[melloware]

More info and test case: #33018

[gsmet]

Closing this one in favor of #32893 .