Closed radistao closed 4 months ago
Please use the Jakarta variant library that depends on the new artifacts.
Thank you very much Chris! I didn't know it's possible by the classifier. Shame on me: i needed to suspect that as there are both javax
and jakarta
dependencies in the code
But still it would be nice to have it more explicitly to mention in a doc. i haven't found it in https://www.ehcache.org/documentation/ or Hibernate Guide , but maybe i overlooked...
@chrisdennis BTW, do you think it has sense in the future to make jakarta
version as default and javax
by classifier?
It's something we're considering for the next time we do a major release (i.e. Ehcache 4)... but it's not something we can do in a minor/dot and it's not really motivating a major bump in isolation.
clear, thank you Chris
javax.xml.bind » jaxb-api v2 is outdated for 6 years already and migrated to jakarta.xml.bind » jakarta.xml.bind-api v4, but Ehcache still depends on the old API and implementation, in particular https://github.com/ehcache/ehcache3/blob/561af430d76847a2c8aa1ba507cf3e142ad9185e/ehcache-xml/src/main/java/org/ehcache/xml/ConfigurationParser.java#L43
For example, having:
spring-boot-starter-cache
,hibernate-jcache
,ehcache
hibernate.javax.cache.uri=ehcache.xml
(Hibernate Guide)javax.xml.bind:jaxb-api
not provided or excluded, butjakarta.xml.bind:jakarta.xml.bind-api:4.0.2
providedThe application throws exception
javax.xml.bind.ValidationEventHandler
defined injavax.xml.bind:jaxb-api
butjakarta.xml.bind:jakarta.xml.bind-api
definesjakarta.xml.bind.ValidationEventHandler
Will the be migrated to
jakarta.xml
any time soon?Thank you.