On SQL Anywhere 17.0.0.1062 the product name is "SQL Anywhere" and
not "Adaptive Server Anywhere".
I suggest to include this string in the test to select the right dialect.
- Previously, the CallbackRegistryConsumer/JpaBootstrapSensitive injections were not performed on new listeners that
were appended using duplication strategy with REPLACE_ORIGINAL, which could lead to NullPointerException when the
listener was invoked (for example for a listener which is a CallbackRegistryConsumer, as the callbackRegistry field
was not set)
- Added calls to checkAgainstBaseInterface and performInjections on the listener, in the case of appending a listener
which replaces an existing one
- Added test cases to verify that the callbackRegistry is being injected
* Move the interface back from org.hibernate.metamodel.model.domain.spi to org.hibernate.metamodel.spi
* Restore method addNamedEntityGraph(String graphName, EntityGraph<T> entityGraph)
* Make sure that findEntityGraphsByType returns List<EntityGraph<? superT>> once again,
and not List<RootGraphImplementor<? super T>>.
Resolve the hibernate.javax.cache.uri using the ClassLoaderService.
Strip the classpath:// prefix if not resolved by new URL() in ClassLoaderService.
This way, if a framework (e.g. Spring) has installed a handler for classpath://, the resource is resolved with its handler and class loader.
If not, we remove the classpath:// prefix and we resolve the resource with our classloader.
We previously erased that class loader, which is not a great idea, in
particular when we use libraries such as JAXB which rely on the TCCL, to
some extent.
Without this patch, we cannot make the OSGi integration work correctly
with Java 9 and above, because the JAXB APIs won't find the JAXB
runtime.
Previously we would only add the dependency when building with JDK9+,
and we built all releases using JDK8.
This means the dependencies were useless, because they would never be
mentioned in the actual POMs published to users.
We don't need to depend on JAXB's compiler (XJC) in our modules,
we just need the dependency in specific tasks during the build.
In particular we don't want users to transitively depend on XJC.
Also, we don't need an explicit dependency to JAXB in every module,
having one in hibernate-core is enough.
