Jersey message body reader not found in maven-built JAR

Question

My application uses a REST (JAX-RS Jersey) interface. When I run it in Eclipse, everything' s fine. The domain objects are annotated, I'm not using XML files for the REST mapping.

Now I created a standalone JAR using the maven-assembly-plugin, which packs the application and all dependencies in a single, executable JAR file. This also seems to work.

But when I start the application and request an object from the server, Jersey complains, that it can't find a message body reader:

com.sun.jersey.api.client.ClientHandlerException: A message body reader for Java type, class de.rybu.atuin.core.entity.User, and MIME media type, application/json, was not found

Any ideas why this happens?

EDIT: After I slept a night over it, I noticed that it complains about JSON... but I'm using only XML for serialization. Strange.

Answer 1

I run into the same issue, searching on stackoverflow, I found that adding jersery-json-1.x.jar into WEB-INF/lib like suggested by this solution will solve the issue. Please give award to Mikhail!

Answer 2

I fixed the problem and I guess I know how :-)

My resources were annotated like this:

@Produces( { MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })
@Path(CONTEXT_ADDRESS)
public class UserResource
{
}

My client used the reverse order:

WebResource wr = ...
User user = wr.accept(MediaType.APPLICATION_JSON_TYPE, MediaType.APPLICATION_XML_TYPE).get(new GenericType<User>(){});

I don't know what initially caused the problem but I completely removed JSON-support and now it works. Maybe it would have been sufficient to simply swith the order of JSON and XML in the client but I didn't try that.

Answer 3

I ran into a similar problem (worked fine running from eclipse or deployed as separate jars but not from executable jar) and found that this approach for creating executable jars using the maven dependency plugin and maven jar plugin works properly. This is because it puts the dependencies in a separate lib directory and then includes that in the classpath in the manifest as opposed to merging them all together which can cause numerous issues.