I have Jax-rs endpoint deployed in WAR archive on JBoss 7.1.1.
In its JSON response I don't want my null field name to be included, so I put #JsonSerialize on it.
class MyResponse {
private Long id;
#JsonSerialize(include = JsonSerialize.Inclusion.NON_NULL)
private String name;
private List<String> addresses;
// getters and setters
}
My pom.xml has the following
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jaxrs</artifactId>
<version>2.3.2.Final</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jackson-provider</artifactId>
<version>2.3.2.Final</version>
<scope>provided</scope>
</dependency>
When the scope for resteasy-jackson-provider is set to provided it ignores the annotation and returns null in JSON response. However when I remove the scope from maven dependency - it works.
From the page here https://docs.jboss.org/author/display/AS71/Implicit+module+dependencies+for+deployments it looks like JBoss should autoload this module if Jax-RS deployment found.
Now I don't know if this is a bug and if I should really include this dependency (NOT keeping it provided). Or maybe I'm doing something wrong there?
You need to make sure to create a JBoss Deployment Structure descriptor.
Since this is a Maven project I assume it would be under src/main/webapp/WEB-INF/jboss-deployment-structure.xml
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
<deployment>
<dependencies>
<module name="org.codehaus.jackson.jackson-core-asl" />
<module name="org.codehaus.jackson.jackson-mapper-asl" />
</dependencies>
</deployment>
</jboss-deployment-structure>
This will allow the built-in support for RESTEasy and Jackson to work correctly in JBoss 7.1.x or JBoss EAP 6.x. Without this descriptor RESTEasy will use the Jettison provider.
Related
I am trying to configure OpenAPI with swagger to my existing non-spring boot application.
Spring v.5.1.8.RELEASE
SpringDoc v.1.4.6
Spring-boot v.2.3.2.RELEASE
Open doc and swagger with spring mv
My application is not spring boot enable that’s why I have following dependencies in my Pom copied from article linked above
<dependency>
<groupId>org.springdoc</groupId>
<artifactId>springdoc-openapi-ui</artifactId>
<version>last.version</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot</artifactId>
<version>2.1.11.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-autoconfigure</artifactId>
<version>2.1.11.RELEASE</version>
</dependency>
My Spring mvc project already has servlet context configuration so I assumed I only need to register/import open api and swagger configuration files.
So I did the following
#EnableMvc
#Configuration
#import({org.springdoc.ui.SwaggerConfig.class,
org.springdoc.core.SwaggerUiConfigProperties.class, org.springdoc.core.SwaggerUiOAuthProperties.class,
org.springdoc.webmvc.core.SpringDocWebMvcConfiguration.class,
org.springdoc.webmvc.core.MultipleOpenApiSupportConfiguration.class,
org.springdoc.core.SpringDocConfiguration.class, org.springdoc.core.SpringDocConfigProperties.class,
org.springframework.boot.autoconfigure.jackson.JacksonAutoConfiguration.class
#Bean
Public OpenAPI(){
return new OpenAPI();
}
When I run my application I gets the following error
“Java.lang.NoSuchMethodError:org.springframework.core.type.AnnotatgedTypeMetadata.getAnnotations()/Lorg/springframework/core/annotations/MergeAnnotations”
It was caused due to incompatible version of spring mvc and spring-boot
I'm trying to mock with powermockito my custom local service util, but i always get an error.
#RunWith(PowerMockRunner.class)
#PrepareForTest({ServiceSubscriptionLocalServiceUtil.class})
public class CStreamTest {
#Before
public void setUp() throws NoSuchFieldException, IllegalAccessException {
.........
mockStatic(ServiceSubscriptionLocalServiceUtil.class);
.........
}
}
and i'm getting the following error :
java.lang.ExceptionInInitializerError
at sun.reflect.GeneratedSerializationConstructorAccessor4.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.objenesis.instantiator.sun.SunReflectionFactoryInstantiator.newInstance(SunReflectionFactoryInstantiator.java:48)
at org.objenesis.ObjenesisBase.newInstance(ObjenesisBase.java:73)
at org.mockito.internal.creation.instance.ObjenesisInstantiator.newInstance(ObjenesisInstantiator.java:19)
at org.mockito.internal.creation.bytebuddy.SubclassByteBuddyMockMaker.createMock(SubclassByteBuddyMockMaker.java:47)
at org.mockito.internal.creation.bytebuddy.ByteBuddyMockMaker.createMock(ByteBuddyMockMaker.java:25)
at org.powermock.api.mockito.mockmaker.PowerMockMaker.createMock(PowerMockMaker.java:41)
at org.mockito.internal.util.MockUtil.createMock(MockUtil.java:35)
at org.mockito.internal.MockitoCore.mock(MockitoCore.java:62)
at org.mockito.Mockito.mock(Mockito.java:1896)
at org.powermock.api.mockito.internal.mockcreation.DefaultMockCreator.createMethodInvocationControl(DefaultMockCreator.java:108)
at org.powermock.api.mockito.internal.mockcreation.DefaultMockCreator.doCreateMock(DefaultMockCreator.java:61)
at org.powermock.api.mockito.internal.mockcreation.DefaultMockCreator.createMock(DefaultMockCreator.java:53)
at org.powermock.api.mockito.internal.mockcreation.DefaultMockCreator.mock(DefaultMockCreator.java:40)
at org.powermock.api.mockito.PowerMockito.mockStatic(PowerMockito.java:62)
at com.e.c.stream.impl.test.CStreamTest.setUp(CStreamTest.java:50)
i add some parts of my pom.xml :
<dependency>
<groupId>org.assertj</groupId>
<artifactId>assertj-core</artifactId>
<version>3.12.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>2.24.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-all</artifactId>
<version>1.10.19</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-core</artifactId>
<version>2.0.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-module-junit4</artifactId>
<version>2.0.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-api-mockito2</artifactId>
<version>2.0.0</version>
<scope>test</scope>
</dependency>
Any ideas ?
Thanks
Liferay's *LocalServiceUtil classes contain a bunch of static methods that just simplify the lookup of an actual service implementation. Given that you state you're on Liferay 7, you should just utilize the services themselves and rely on #Reference dependency management and injection in the code that uses them. This way you just need to mock a regular interface that is not loaded with some default implementation and lookup.
Another option is to test the implementation - and write tests for the code "above" the service, as well as its implementation. It's typically hard to write UI-layer code, e.g. portlets, in a test-driven fashion, where mocking isn't heavily dependent on the implementation of the service and the calling classes.
Normally services utility classes created by Service builder do not have a no arg constructor, not even a constructor for that matter.
But if you check the log you will see and this is your issue:
New instance of the class is created inside PowerMock.
java.lang.ExceptionInInitializerError at sun.reflect.GeneratedSerializationConstructorAccessor4.newInstance(Unknown Source)
After trying to create an instance for: ObjenesisBase....
Even though it has not constructors, services utils normally initialize static members, like a ServiceTracker.
You could create a bummy service impl or your code could use the service reference instead of the util, you could mock that guy. Several options here, even mocking methods that give you the service to give you a dummy service.
But in summary, you cannot just do:
mockStatic(ServiceSubscriptionLocalServiceUtil.class);
As this will create an instance, and that instance has static members that need to be initialized.
I am using Maven and Jersey on Tomcat7 to build a web server, but I keep getting a 415 response. My request is made using Postman and Advanced Rest Client
My stubbed method:
#POST
#Path("/createuser")
#Consumes(MediaType.APPLICATION_JSON)
public Response createUser(UserInformation user){
return Response.ok().build();
}
Custom class:
package efile.models;
import com.fasterxml.jackson.annotation.JsonInclude;
import com.fasterxml.jackson.annotation.JsonInclude.Include;
#JsonInclude(Include.NON_NULL)
public class UserInformation {
private String id;
private String username;
private String password;
private String firstName;
private String lastName;
private String emailAddress;
/* getters and setters */
}
Request:
{myhost}/createuser
Headers:
accept: application/json
content-type: application/json
Request body:
{
"id":"1234567",
"userName":"qwer",
"password":"zxcv",
"firstName":"jasdfme",
"lastName":"qwetad",
"emailAddress": "qwet#gf4elk.com"
}
My dependencies:
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.25</version>
</dependency>
<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>jsr311-api</artifactId>
<version>1.1.1</version>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-server</artifactId>
<version>1.17</version>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-bundle</artifactId>
<version>1.17</version>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-servlet</artifactId>
<version>1.17</version>
</dependency>
<dependency>
<groupId>com.dropbox.core</groupId>
<artifactId>dropbox-core-sdk</artifactId>
<version>1.7.6</version>
</dependency>
<dependency>
<groupId>org.jvnet.mimepull</groupId>
<artifactId>mimepull</artifactId>
<version>1.9</version>
</dependency>
<dependency>
<groupId>com.sun.jersey.contribs</groupId>
<artifactId>jersey-multipart</artifactId>
<version>1.17</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-io</artifactId>
<version>1.3.2</version>
</dependency>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
<version>2.3.2</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
<version>2.2.0</version>
</dependency>
Thanks.
On my side it was because I forgot to add
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-json-jackson</artifactId>
<version>2.18</version>
</dependency>
after
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>2.18</version>
</dependency>
No warnings/errors at compilation but 415 Unsuported Media Type at runtime trying to consum JSON on Jersey 2.18 running on AppEngine
Hope it helps
If you are sending the 'Accept' header, you may also need to add the #Produces(MediaType.APPLICATION_JSON) annotation to your method, or, remove the Accept header from the request if you are not expecting a response body.
Edit:
Ok... After a bit of experimentation, I believe I have been able to reproduce your problem and find a solution.
I see from your pom file that you are using Jersey 1.17. I reproduced your problem using Jersey 1.18, but I suspect it is equally valid for 1.17. It appears that Jersey does not come with Jackson support built in, but Jackson must be installed as a provider. I've always used it with containers like Glassfish where the providers come pre-configured.
I was not able to make Jersey 1.18 work with the latest Jackson 2 libraries (under the com.fasterxml.jackson groupId) that you were pulling in with your pom.xml, but I was able to get it working with the older Jackson libraries when the groupId was still org.codehaus.jackson. It appears that Jersey 1.18 uses a class called com.sun.jersey.json.impl.provider.entity.JacksonProviderProxy which looks specifically for a Jackson implementation in org.codehaus.jackson... So you might not be able to make the newer versions of Jackson work without upgrading to a newer version of Jersey.
Firstly, I added the XmlRootElement annotation to the UserInformation class. Jax-RS will serialize and deserialize JAXB objects and this annotation marks this class as a JaxB object. This required an additional dependency in the pom on the jaxb-api:
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.1</version>
</dependency>
Next, I removed all of the Jersey dependencies from your pom.xml file, and added a dependency on the jersey-server to give access to the necessary JaxRS annotations:
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-server</artifactId>
<version>1.18</version>
<scope>provided</scope>
</dependency>
I then took a clean installation of Tomcat 7.0.52, and added the following jars to the CATALINA_HOME/lib directory:
asm-3.3.1.jar (Byte code manipulation used by Jackson)
jacksore-core-asl-1.9.13.jar (Includes the Jackson JSON Provider)
jersey-bundle-1.18.jar (The Jersey Implementation)
I found it necessary to add these jars to the Tomcat lib folder rather than include them in the project WAR file. I don't work with Tomcat much, so I don't recall the rules about exactly when it is necessary to place jars in the Tomcat lib directory vs. including them in the WAR file.
Following all of those steps I was able to go from getting the 415 Media Unsupported error to a 200 OK on the POST.
I hope this helps.
I was able to resolve the issue after modifying the dependencies in the pom.xml. I updated the jersey dependencies to 1.18.1 and added the fasterxml json provider dependency:
<dependency>
<groupId>com.fasterxml.jackson.jaxrs</groupId>
<artifactId>jackson-jaxrs-json-provider</artifactId>
<version>2.2.1</version>
</dependency>
My guess is that it was just the json-provider dependency that resolved the issue.
How could I set JSON provider for RestEasy at JBoss 7.1.1?
RestEasy documentation says:
RESTEasy allows you to marshall JAXB annotated POJOs to and from JSON.
This provider wraps the Jettison JSON library to accomplish this.
But I found that it seems that on JBoss 7.1.1 Resteasy uses Jackson provider because #XmlTransient on my class field was ignored, but #JsonIgnore was processed.
How can I tell to Resteasy to use Jettison instead of Jackson?
On Jboss I found both providers.
if you just want to have a different module pulled than the standard, you can provide this in a jboss specific deployment descriptor.
Read https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7 to learn the details, and read https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+for+deployments to learn what modules JBoss uses by default.
To exchange the two providers, provide a META-INF/jboss-deployment-structure.xml with the following content below.
This switched the provider for me.
Br Alexander.
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.jboss.resteasy.resteasy-jackson-provider" />
</exclusions>
<dependencies>
<module name="org.jboss.resteasy.resteasy-jettison-provider" />
</dependencies>
</deployment>
</jboss-deployment-structure>
As a follow-on to ahus1's answer: if you have a multi-level deployment archive (i.e. a top-level EAR file containing an EJB jar and a war file), you will need to configure the exclusion of org.jboss.resteasy.resteasy-jackson-provider on whichever sub-deployment contains the RESTEasy/JAX-RS components.
In my deployment, for example, my REST endpoints were annotated on top of EJBs in my EJB jar file, while my #ApplicationPath-annotated javax.ws.rs.core.Application subclass which activates RESTEasy was in my war file. I found that the approaches of putting the exclusions solely on the top-level (EAR) deployment (as in ahus1's example) or on the EJB-jar-level deployment were ineffective, but I finally got RESTEasy to use Jettison rather than Jackson by putting the exclusions on all 3 levels (EAR, EJB, Web):
<?xml version="1.0" encoding="UTF-8" ?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclusions>
<module name="org.jboss.resteasy.resteasy-jackson-provider" />
</exclusions>
<dependencies>
<module name="org.jboss.resteasy.resteasy-jettison-provider" />
</dependencies>
</deployment>
<sub-deployment name="MyApp-ejb.jar">
<exclusions>
<module name="org.jboss.resteasy.resteasy-jackson-provider" />
</exclusions>
<dependencies>
<module name="org.jboss.resteasy.resteasy-jettison-provider" />
</dependencies>
</sub-deployment>
<sub-deployment name="MyApp.war">
<exclusions>
<module name="org.jboss.resteasy.resteasy-jackson-provider" />
</exclusions>
<dependencies>
<module name="org.jboss.resteasy.resteasy-jettison-provider" />
</dependencies>
</sub-deployment>
</jboss-deployment-structure>
It's very likely that I only needed the exclusions on the subdeployments, and putting it on the main EAR deployment is superfluous; I didn't try it that way, since for now putting it on all three seems to work perfectly well.
From what I observed right now, Jackson is the default in JBoss AS 7.1.2.
First, the RestEasy modules are hidden from app's classloader, which IMO should not be.
So I just filed https://issues.jboss.org/browse/AS7-5605 .
Second, to your question: To set the particular provider, you need to remove it from classloader's spot in AS - so again, to go module.xml's and comment out those providers which you don't want to use - if Jackson is available, RestEasy uses it; otherwise it uses Jettison.
Also, add them your project as a compile time dependency, so you can use their specific annotations. Example:
<!-- RestEasy -->
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>jaxrs-api</artifactId>
<version>2.3.4.Final</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-core-asl</artifactId>
<version>1.9.2</version>
<scope>provided</scope>
</dependency>
Note: Until AS7-5605 is done, you need to set the versions manually.
After (in later versions of AS), you have to remove these versions and use those defined in JBoss BOM. See JBoss AS QuckStarts for example.
Feel free to create and contribute a QuickStart of RestEasy using alternative provider.
I added this line to standalone.conf.bat/sh and it solved my problem.
set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true"
I have a really simple webapp project with maven and jetty that has been working very well until now. But now I need to setup MySQL connection pooling with JNDI as the database connections always time out.
First of all here is the relevant content of my pom.xml:
<modelVersion>4.0.0</modelVersion>
...
<packaging>war</packaging>
...
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<jetty-version>8.1.0.v20120127</jetty-version>
</properties>
<dependencies>
...
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.20</version>
</dependency>
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>${jetty-version}</version>
<type>maven-plugin</type>
</dependency>
</dependencies>
...
<build>
<plugins>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>${jetty-version}</version>
<configuration>
<scanIntervalSeconds>10</scanIntervalSeconds>
</configuration>
</plugin>
</plugins>
...
</build>
Now I created a jetty-env.xml in the folder /src/main/webapp/WEB-INF with the following content:
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
<New id="project-db" class="org.eclipse.jetty.plus.jndi.Resource">
<Arg>jdbc/db</Arg>
<Arg>
<New class="com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource">
<Set name="url">jdbc:mysql://www.example.com:3306/mydb</Set>
<Set name="username">dbuser</Set>
<Set name="password">dbpass</Set>
</New>
</Arg>
</New>
</Configure>
But the problem is that I can't even test if this connection works as the jetty-maven-plugin fails to start on the goal
mvn jetty:run
with the following error:
WARN:oejw.WebAppContext:Failed startup of context o.m.j.p.JettyWebAppContext
{/,file:/D:/documents/programmierung/workspace/battleships-trunk/src/main/webapp/}
,file:/D:/documents/programmierung/workspace/battleships-trunk/src/main/webapp/
java.lang.IllegalArgumentException: Object of class
'org.mortbay.jetty.plugin.JettyWebAppContext' is not of type
'org.eclipse.jetty.webapp.WebAppContext'.
Object Class and type Class are from different loaders.
So how can I get this to work? I'm forced to use Jetty version 8.x as I need WebSocket support and as the remote productive server will be running Jetty 8.
EDIT
Before Pavel Veller's answer I tried the following: Deployed the assembled war to the remote jetty8 server and got the same error only that the previous error now reads as follows:
java.lang.IllegalArgumentException: Object of class
'org.eclipse.jetty.webapp.WebAppContext' is not of type
'org.eclipse.jetty.webapp.WebAppContext'.
Object Class and type Class are from different loaders.
So it seems as if there are multiple class loaders conflicting.
EDIT2
As requested by Pavel I recreated the error with a simplified webapp which you can find here on Dropbox. It is a zipped eclipse maven project.
Try removing the dependency on jetty-maven-plugin- this dependency adds the plugin to the WAR, which you don't want.
If you need to use any classes from Jetty itself, add a dependency for the specific version of Jetty (rather than the plugin) with a scope of provided.
It looks like it's pulling jetty 6 from somewhere. The exception you're seeing seems to be coming from the code that parses jetty-env.xml (org.mortbay.jetty.plus.webapp.EnvConfiguration). The XMLConfiguration class compares the class you declare on the Configure element with the actual class of what it gets from getWebAappContext(). The latter is instance of org.mortbay.jetty.plugin.JettyWebAppContext in your case and you expect it to be org.eclipse.jetty.webapp.WebAppContext (which would be the parent class for JettyWebAppContext had they both come from the same "namespace").
It's hard to tell where that would be happening from but maybe inspect your .m2 and confirm you have the proper binaries for your jetty dependencies? It has got to be running not the version you expect it to run.
UPDATE. Jetty does the following when it loads the classes defined in the configuration:
first load with Thread.currentThread().getContextClassLoader() and
loop through all getParent() until all options are exhausted.
if not successful, attempt to load with the class loader that loaded
jetty core classes (XmlConfiguration.class.getClassLoader())
looping through all the parents as well.
If still not successful, do a Class.forName()
Report ClassNotFoundException if not successful.
you can see it in the code of org.mortbay.util.Loader(http://grepcode.com is a great resource for a quick look under the hood)
It does load the class in your case, but apparently not with the right class loader.
I would now assume you have an extra jetty JAR somewhere on your classpath that interferes with the order of things.
Had a same issue caused by :
<useTestClasspath>true</useTestClasspath> (true instead of false)
That put a extra jetty jar in the classpath...
Including the dependency scope solved the error for me.
<scope>provided</scope>
In the pom.xml it looks like this,
<!-- JETTY DEPENDENCIES -->
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-server</artifactId>
<version>${jetty.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-servlet</artifactId>
<version>${jetty.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-webapp</artifactId>
<version>${jetty.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-servlets</artifactId>
<version>${jetty.version}</version>
<scope>provided</scope>
</dependency>
in the jetty dependencies and the errors went off. And btw, the jetty version I'm using is 9.3.7.v20160115.
I had the same issue and fixed it but can't figure out why.
By changing
org.eclipse.jetty.webapp.WebAppContext
to
org.eclipse.jetty.maven.plugin.JettyWebAppContext
it started to work for some reason, can't figure out exactly why. Clearly maven plugin has something to do with it?