Archie L. Cobbs

> Static resources are always served from /VAADIN in the context path. Well this explains the problem, but yuck - isn't that a layering violation? A WAR file is no...

Reopening bug because it sounds like it's worth reconsidering this behavior.

This is actually worse than I thought. This bug also seems to be causing failure to load add-ons. I'm using this: ```xml de.f0rce ace 3.3.3 ``` And the syntax highlighting...

I just realized this whole problem is trivial to fix. The basic problem is that before we serve resources from the classpath, we have to strip off `request.getServletPath()` from the...

Here are some [related Payara bugs](https://github.com/payara/Payara/issues?utf8=%E2%9C%93&q=is%3Aissue%20NoSuchMethodError). Upgrading to Payara 5.x may fix the problem.

Hi @Legioth, > Without any specific servlet mapped to a path, a request to contextPath/foo/bar.txt would be served by the file from src/main/webapp/foo/bar.txt if built as a WAR file with...

> I realize that https://github.com/vaadin/flow/issues/13769 causes problems with add-ons, but the reason it was fixed in the first place was that the other way also caused problems. I would like...

> We decided to revert the change for serving static resources from context root https://github.com/vaadin/flow/pull/14357 and fix Vite-related issue https://github.com/vaadin/flow/issues/13190 in another way. Thus, not sure this PR would be...

I've updated this pull request to include a new unit test (apologies for omitting it previously). Also there are a couple of changes to other unit tests which get broken...

@mcollovati, > It seems like the problem is StaticFileServer not stripping servletPath before trying to load requested resource from classpath. Yes that makes sense... in fact, I already have a...