|Re: [jetty-users] TryFilesFilter giving ClassNotFoundException|
Hi, On Wed, Jun 17, 2020 at 6:16 PM Peter Boughton <jetty@xxxxxxxxxxxxxxxxx> wrote: > > Thanks Simone - that has helped get it working, with caveats... > > I did the following: > > mkdir webapps/ROOT/WEB-INF/lib/ > cp ../jetty-distribution-9.4.30.v20200611/lib/fcgi/fcgi-server-9.4.30.v20200611.jar webapps/ROOT/WEB-INF/lib/ > java -jar ../jetty-distribution-9.4.30.v20200611/start.jar --module=http,deploy > > The context starts, and serves files that exist, but it's not using missing.html for non-existing files, and for http://localhost:8080/ it's giving 500 error with java.lang.NoClassDefFoundError: org/eclipse/jetty/util/StringUtil > > java.lang.NoClassDefFoundError: org/eclipse/jetty/util/StringUtil > at org.eclipse.jetty.fcgi.server.proxy.TryFilesFilter.resolve(TryFilesFilter.java:136) > at org.eclipse.jetty.fcgi.server.proxy.TryFilesFilter.doFilter(TryFilesFilter.java:93) > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:549) > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602) > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) > > I got past that error by copying jetty-util too: > > cp ../jetty-distribution-9.4.30.v20200611/lib/jetty-util-9.4.30.v20200611.jar webapps/ROOT/WEB-INF/lib/ > > Only it then complained "java.net.MalformedURLException: maintenance.html" so I guessed I had to add a / to the start of both maintenance.html and missing.html and the context starts up without any errors. > > Requiring the files to start with / is different to what the API docs say, so this is either a code bug or a documentation bug. Thanks for the thorough exercise of getting this working! Please file an issue about the lack of "/" - I'd lean towards fixing the documentation (if you want to propose a PR will be great). > Even though there were no errors it still wasn't sending non-existent files to missing.html, but I realised that was a config issue - I needed to correct the filter mapping from / to /* so it actually applied. > > So, my simple test case is working, but if there are any fixes to the two jar files it means remembering to manually re-copying them on Jetty upgrades, which I'd much rather avoid. Your *.war is now depending on some Jetty library. Therefore I assume that you have a build tool (e.g. Maven) that creates your war with the right dependencies. If that's true, then you don't need to manually re-copying - you just update the Jetty version in your build configuration file and you're done. > It looks like I can use extraClasspath in a WebAppContext for that purpose, so I removed the lib directory, and created a webapps/ROOT.xml file which included: > > <Set name="extraClasspath"><SystemProperty name="jetty.home"/>/lib/fcgi/fcgi-server-<SystemProperty name="jetty.version"/>.jar,<SystemProperty name="jetty.home"/>/lib/jetty-util-<SystemProperty name="jetty.version"/>.jar</Set> But if you use this Jetty context XML file, then why don't you add the TryFilesFilter like it is done for FastCGI, rather than adding it in web.xml? Your deployment will need this ROOT.xml file to work (with the TryFilesFilter configuration in it), but you won't have to change your build or do any manual copy. -- Simone Bordet ---- http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts.
Back to the top