0

When developing a JAX-RS (Jersey) application, I use @XmlRootElement and @XmlElementto enable XML Media type as a response body.

Exception:
21-Jan-2019 12:29:28.601 SEVERE [http-nio-8080-exec-4] org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo MessageBodyWriter not found for media type=text/plain, type=class org.mypack.model.Message, genericType=class org.mypack.model.Message.

Any tips?

Giorgi Tsiklauri
  • 9,715
  • 8
  • 45
  • 66
  • classpath, module-path or modules. More details like exception would probably help. – hotzst Jan 21 '19 at 10:28
  • I've said the reason, but ok, now I've added the trace. Did it help anyhow? – Giorgi Tsiklauri Jan 21 '19 at 10:32
  • Are you aware that JAXB has been removed from JDK 11, and that you need to add it to your classpath yourself? Did you do that? Your question is sorely lacking in relevant information. – Andreas Jan 21 '19 at 10:50
  • 1
    Yes, I am, and I add that to the classpath. Thank you for the comment, but I'd say that if one asks the question about JAXB, the one should be aware of what is classpath. It compiles and runs.. the exception is runtime. – Giorgi Tsiklauri Jan 21 '19 at 11:06
  • @Andreas, btw, are you aware that it all worked fine even with jdk11 and the problem wasn't jdk? Don't put the negative "I know everything" tone in your comments next time, please. Thank you. – Giorgi Tsiklauri Jan 23 '19 at 09:25
  • @GiorgiTsiklauri I don't know all, which is why I *asked* you. It is a very common cause of JAXB issues with JDK 11, and your question didn't say that you'd already fixed that, so it was an obvious area to cover, with a *question*, so I did. And as far as I can see from your self-answer, the problem was entirely about JAXB being removed from JDK 11. – Andreas Jan 23 '19 at 17:21

1 Answers1

-1

SOLUTION

I've heard that many people have this problem/question, so I think the solution I've found would be better shared, and I'll even explain it in a bit details:

There are actually two distinct points of this problem I was considering:

  1. jdk version for building(compiling) the project;
  2. jdk version for the Web Container (Tomcat) you're going to run your project on (in IntelliJ, it's under Run/Debug Configurations, you will have to specify the jdk for your server).

Turns our, that it does not matter whether you'll use java compiler/jdk 8 or 11, it works in both cases, you've built it with jdk8 or jdk11 (You'll just have to consider, that by default jaxb (package javax.xml.bind.annotation) is removed from jdk11, so you'll add it manually as a dependency/jar). What really matters, is the version of Java you're providing for your Web Container.

If (for instance) Tomcat will run on jdk11, JAXB won't work even if you'll have it on the classpath and disregarding of which version of Java you used to build your project. On the other hand, if you'll provide the jdk8 as a platform for your server (Edit/Debug Configurations in IntelliJ), then JAXB will work disregarding of which Java you've used to build your project (with jdk11 you'll add a dependency/jar, with jdk8 it's provided in rt.jar).

Giorgi Tsiklauri
  • 9,715
  • 8
  • 45
  • 66
  • *"run on jdk8, JAXB won't work"* then *"if you'll provide the jdk8 [...] then JAXB will work"* Huh? You're contradicting yourself. – Andreas Jan 23 '19 at 17:24
  • I'm sorry, that was an mechanical typo. I've only changed jdk8 with jdk11 in that clause. – Giorgi Tsiklauri Jan 23 '19 at 19:08
  • *"[If] run on jdk11, JAXB won't work even if you'll have it on the classpath"* That is incorrect. If you run on JDK 11, you *can* make JAXB run by adding the appropriate jar files to your web applications `WEB-INF/lib` folder. – Andreas Jan 23 '19 at 21:29
  • @XmlElement (for instance) is not working on Tomcat, as I've stated, when Tomcat runs on jdk11, and works when Tomcat runs on jdk8. – Giorgi Tsiklauri Jan 24 '19 at 05:28
  • What does *"is not working"* mean? If you add *all* necessary JAXB jars, it'll work. – Andreas Jan 24 '19 at 19:11