Property "hibernate.javax.cache.uri" is ignored in JakartaEE deployments

[mletenay]

Situation:
JakartaEE application with EAR file consiting of several EJB JAR modules, each with its own persistence context and its own hibernate 2nd level cache config.

Problem:
Migrating from EhCache 2.x to Caffeine, but as of 3.1.8 it does not work and completely ignores the hibernate.javax.cache.uri specified in persistence.xml descriptors.
The issue with "hibernate.javax.cache.uri" was already partially addressed in #877 but that solution works only for Spring application.

As mention in #877 (comment) from security reasons, the uri loading was limited to file: and classpath: protocols.
The actual trouble is that in case of JakartaEE, the URI is neither of those but something like jar:file:/ejbmodule.jar!/META-INF/specific-cache.conf.

The fix is trivial, just add jar: protocol handling to TypesafeConfigurator#resolveConfig, I will create PR for that ...

[ben-manes]

Thank you! I’m hoping to get caught up over the weekend for this and the other two recent requests. Until this is released, you can use setConfigSource to resolve using your application strategy.

[ben-manes]

I merged this a little early to base the unit test on top of. It took a little build magic to make an extra test resource jar that is placed on the classpath, so that the resource lookup resolves using the jar scheme. That uri is working so just need to duplicate the tests cases. I might get everything wrapped up this weekend for a release, but no promises.

[mletenay]

I've looked at the unit tests when pushed my commit, but I am more junit/maven guy and your setup is slightly above my skills...
Anyway, thanks for nice library.

[mletenay]

Sorry to bother you, but it would be nice to have a new release so we do not have to hack around this issue with custom call of seeConfigSource ...
Thanks a lot.

[ben-manes]

sorry, I wasn't as active recently and spent time investigating recent claims that our eviction policy was under performing when compared to new algorithms from CMU. It seems they made very minor, mostly inconsequential changes to old algorithms and the issue they observed was with their attempt to reimplement our algorithms. Caffeine aced their workload traces whereas their algorithms did poorly on the wider set of traces that I use. I'll try to get back to the outstanding issues to unblock a release.

[ben-manes]

Released in 3.2.0 (sorry for the delay)