-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Nicolaj,
On 8/8/18 1:17 AM, Nicolai Parlog wrote: > Hi, > > with the help of an answer on StackOverflow we have solved this. > In case anybody was watching this, here's what happened... > > First some random facts: > > * if not given a class loader > (https://javaee.github.io/jaxb-v2/doc/user-guide/ch06.html#d0e6919), > > `JAXBContext::newInstance` will use [the thread's context class > loader > (https://docs.oracle.com/javase/10/docs/api/java/lang/Thread.html#getC ontextClassLoader()) > > when looking for the JAXB implementation - this is the case even if > you call `newInstance(Class...)` (one might mistakenly think it > uses the provided class instances' loader) * Tomcat builds a small > class loader hierarchy > (https://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html) > to separate web applications from one another * by not relying on > the module _java.xml.bind_, in Java 9, JAXB classes are not loaded > by the bootstrap or system class loader > > So here's what happened on Java 8: > > * we don't pass a class loader to JAXB (oops), so it uses the > thread's context class loader * our conjecture is that Tomcat does > not explicitly set the context class loader and so it will end up > being the same one that loaded Tomcat: the system class loader This is almost certainly an incorrect assumption. While an application is processing a request, the TCCL should be that of the webapp's ClassLoader. Any other situation would be a security problem. > * that's dandy because the system class loader sees the entire JDK > and hence the JAXB implementation included therein > > Java 9 enters - the piano stops playing and everybody puts down > their scotch: > > * we added JAXB as a regular dependency > (https://stackoverflow.com/a/48204154/2525313) and so it is loaded > by the web app's class loader * just as on Java 8, JAXB searches > the system class loader, though, and that one can't see the app's > loader (only the other way around) If your above assumption were true, then this would be true. But I believe both of these assumptions are false. It's easy to test your hypothesis: just print the value of the TCCL at the point where you think JAXB is using the wrong one. If it's a WebappClassLoader, then your analysis above is incorrect. If it's printing the (somewhat confusingly called the) "application" ClassLoader or "system" classloader, or "null", then something running in your environment has broken the TCCL, and it's probably no Tomcat's fault. > * JAXB fails to find the implementation and goes belly up > > The solution is to make sure JAXB uses the right class loader. We > know of three ways: > > * call > > `Thread.getCurrentThread().setContextClassLoader(this.getClass().getCl assLoader());` > > but that's not really a good idea > * create a context resolver > > (https://docs.oracle.com/javaee/7/api/javax/ws/rs/ext/ContextResolver. html), > > but that requires JAX-WS and that feels like replacing one evil with > another * use the package-accepting variant of > `JAXBContext::newInstance` that also takes a class loader and pass > the correct loader, although that requires some refactoring JAXB using the TCCL is entirely appropriate. You need to find out why the TCCL is wrong. Try running your application under a SecurityManager and you'll find out where the TCCL is being set pretty quickly :) - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltsezMACgkQHPApP6U8 pFh76BAAlFiN/qNZm5LSXRAriskFn3HMl6+dNdxzQt8xhVJAIvZt9yE+ntA6RMYd vcXGCR/Ttb/f1wKGxKK6sfgifGWJXuL6+XRL6n0DaKicAN9euGY8qZh2wxarp0Aa wa38zY1PemREkPpJZWphwT1jl/XCXzg/d7k+DCmcOMnKoAtGeH/J/AU18ay5dk97 FfDtVSSbMcp1R0QYNkC9rVta7A1cSgzVVnGHzu6sia7KViiG1/3f5yJEM3NlI9pe EYKzo0N2h901TMDpv81NhGs0qeTkQQZHojtQsg7GWs29DQMXNeBP/Wv/ciuriuHA B0E+NtS3MJRY2LZ3XTBPx3BvSY5giUGolt7tU6LDtKEMuiDMFkCrtdi5Useo1BTt OJZxaphzuqPG94DhsO5b4/t9hNuZ1YurKZDcQ7j2UkI9/TwPiW33ch7T6qzIn6ZO vKi/AAZQsYuOyGEOb7UZj8N2PFMXLXkbv+WX+QtvbnEM/0+s4AHejvxlcLE6I3k3 gUoHwqV+MXccZeEfgKgZm5xURES4AynBXR4BGMbUk6VZOryAVP80G3GKnkebNaK/ RrR0f4WbHDRKOp0azRFDWqmjkKwb4dYJTUWX8hhw1M4oTxRoiJx0pvcjK49sgkaH Fx8MXxhCp00mWY4sOysXtNrHc+Tw8qvonFpO0juLc65/ttSafpI= =GGUk -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
