Add jaxb dependencies

[FrankHossfeld]

This PR fixes an issue with the dynatablerf example. Starting with GWT 2.11.0 the jabx dependencies are no longer available and need to be added.

[jnehlmeier]

Doesn't this provide classes using jakarta package and some imports need to be updated as well somewhere?

[FrankHossfeld]

After adding the dependencies I were able to run the sample with Java 11 & 17 without changing any code. In case we switch to jakarta.xml.bind, we might have code changes. But then, I think, Java 8 will no longer work for that sample.

[jnehlmeier]

Or to be more precise: jaxb-impl:4.x is Jakarta EE 10 (based on jakarta package) and I am wondering if it really matches jaxb-api:2.4.x which should be Jakarta EE 8 (using the javax package).

[FrankHossfeld]

Tested again. The original implementation works well and without error with Java 8, but will fail in Java 11 & Java 17. I think in Java 9 the jaxb package have been removed from the JDK. Starting with Java 9 (I think) the dependencies must be added to the pom to avoid the error.

Checked the PR with Java 8. Works also.

Starting with GWT 2.12.0 - when Java 8 is dropped - we can switch to the jakarta.xml.bind package. This change will have a bigger impact. I expect at least changes on the package names ...

[niloc132]

I'm not sure this is the best solution, but it is a solution - and changing to jakarta for xml doesn't make sense. The issue is that GWT's requestfactory implementation needs some javax.validation implementation (#9844 is not simple it appears, at least to maintain backwards compat, and we've already said that for validation implementations users should look outside of GWT), and the example picks hibernate as the implementation. That particular hibernate version happens to require javax.xml.bind - see from the stack trace:

java.lang.ClassNotFoundException: javax.xml.bind.JAXBException
    at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass (SelfFirstStrategy.java:50)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass (ClassRealm.java:271)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass (ClassRealm.java:247)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass (ClassRealm.java:239)
    at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass (WebAppClassLoader.java:511)
    at java.lang.ClassLoader.loadClass (ClassLoader.java:527)
    at org.hibernate.validator.engine.ConfigurationImpl.parseValidationXml (ConfigurationImpl.java:252)
    at org.hibernate.validator.engine.ConfigurationImpl.buildValidatorFactory (ConfigurationImpl.java:143)
    at javax.validation.Validation.buildDefaultValidatorFactory (Validation.java:111)

...It almost seems like the exclude lines, which keep jaxb-api out of the build should be removed, but as far as I can tell, those excludes don't do anything. Looking at https://search.maven.org/artifact/org.hibernate/hibernate-validator/4.1.0.Final/jar, those dependencies are scope=provided anyway.

So I'm not sure there is a better fix here, aside from "rewrite Editors and RequestFactory to stop using javax.validation apis (SimpleViolation, EditorDriver, subtypes) to use a newer, external implementation of jakarta.validation instead"?

[jnehlmeier]

GWTs documentation says that XML configuration is not supported and Hibernate Validator 4.1 documentation says that JAXB is only needed for XML configuration. If the code does not use XML configuration then you can disable it calling Configuration.ignoreXmlConfiguration() during ValidationFactory creation. If that method is called, it should stop trying to load JAXB.

Maybe we should change RequestFactory server code to probe for JAXB and if not available call Configuration.ignoreXmlConfiguration()?