Embedded Jetty with exploded war, using annotated config

て烟熏妆下的殇ゞ 提交于 2019-11-29 17:59:09

Using ...

webapp.setConfigurations(new Configuration[]{
        new AnnotationConfiguration()});

will undo all of the existing important configurations and only have the AnnotationConfiguration enabled.

No wonder it isn't working for you, with that setup, the configuration that loads WEB-INF/web.xml is missing, the configuration that uses WEB-INF/lib is missing, etc.

You have to modify the existing configuration list appropriately, and there's plenty of examples out there to show you this.

Since you didn't specify if you have annotations that use JNDI, or exist in web-fragments, or come from outside of the webapp context (such as the container itself), the exact configuration you need is tough to specify.

See the https://github.com/jetty-project/embedded-servlet-3.1 project for a complete project that does this.

context.setConfigurations(new Configuration[] 
    { 
        new AnnotationConfiguration(),
        new WebInfConfiguration(), 
        new WebXmlConfiguration(),
        new MetaInfConfiguration(), 
        new FragmentConfiguration(), 
        new EnvConfiguration(),
        new PlusConfiguration(), 
        new JettyWebXmlConfiguration() 
    });

This is a general setup, which is the most common, but might expose you to extra configuration you might not want.

Even if you don't want the other components, you still need to leave them be for a discovered webapp. Otherwise you have a 100% manual webapp, that you specifically call .addServlet() and .addFilter() etc on.

You should probably use this syntax instead.

private void enableAnnotationScanning(Server server)
{
    Configuration.ClassList classlist = Configuration.ClassList.setServerDefault(server);
    classlist.addBefore("org.eclipse.jetty.webapp.JettyWebXmlConfiguration",
            "org.eclipse.jetty.annotations.AnnotationConfiguration");
}

as this will modify the existing list of Configurations to just add the AnnotationConfiguration

If you want to see other examples of this format, look at the following example projects:

After discussing with Joakim Erdfelt I looked further into Tomcat and I understand that Jetty is probably not the best container to test different kinds of Java EE web features. Jetty realises the support of Java EE in other ways than Glasshfish and Tomcat, which in turn requires different setup approach, which is elaborated in the discussion under Joakims answer.

After testing with Tomcat using the following snippet

public class MyServer {

public static void main(String[] args) throws Exception {
    Tomcat tomcat = new Tomcat();
    tomcat.setPort(8080);

    tomcat.addWebapp("","webapp"); 

    tomcat.start();
    tomcat.getServer().await();
    }

 }

it first looked like Tomcat did not require any web.xml, but after further investigating, Tomcat uses a default web.xml if one is not provided. This web.xml includes a <welcome-file>index.html</welcome-file> and a DefaultServlet which serves static content. This approach is similar to Jettys, and I assume this is also how Glassfish works. So lesson learned is that there is always some kind of DefaultServlet that lurks in the background of Java EE web servers, which does some of the magic work. Even if web.xml is optional for the user of the server, the server still provides it behind the scenes to make it self work.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!