New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using custom config source for JCache #312
Comments
If you are okay with creating all caches upfront, you can use You might also consider using the library's system properties, e.g. |
Thanks, I'll leave this open for now if I encounter any problems along the way. |
@cen1 any feedback on this? Are there changes we should invest in, close this out, or...? |
I was very low on time so I haven't been able to start with this yet but I still plan to. I will reopen the issue if I encounter any problems when I come around to it. At least based on the first response, I don't expect any. |
@ben-manes Creating a new Config instance from custom source and merging it with default Config was easy enough.
Now I am missing the part where I could give this Config instance for caffeine to use. Looks like one way would be to write my own provider, extend and override Finally, I would have to add my own If you have some ideas how to tackle this the best way I'll gladly hear it. |
JCache is static and service-loader based, and is actually quite hostile to DI. The classic JDK trick to replace reference implementations is to use a system property (e.g. how I think that would be the most natural and least invasive approach, with only a little refactoring needed to introduce a |
One thing I still need to understand is what is the trigger for jcache initialization (what triggers the service loading). Because I would still need to do two things from framework's
I couldn't find anything but I speculate the cache init is done by some kind of CDI observer? If that is the case, I guess the answer is: before CDI component is loaded by the framework. As for the |
Take a look at |
Sorry, I thought there is some kind of init going on but apparently the answer is "whenever the Whatever you decide the config abstraction in caffeine ends up being I'll try to implement it and give feedback. |
Would a static method on |
For my use case yes, that would be ideal. |
I hacked together a simple patch cen1@0eae3ec probably not exactly what you had in mind but just to get me going. POC also successfully tested. |
Pretty close, sorry I haven't had time for this. The main difference was to use Java 8's |
I am in no particular hurry so if I can get something similar at least as a -SNAPSHOT to depend on in a month or so that would be cool. |
The only difference from your patch is the method is named |
@ben-manes I have published kumuluzee-jcache as a snapshot preview. Are there any near term plans for 2.8.1 or 2.9 release of caffeine? |
Oh, I forgot this didn't make it into 2.8. Thanks for being patient. I can probably cut a release for you over the weekend. There would be nothing else of interest going out, though. |
That would be great. |
@ben-manes just a small reminder to get a release done. |
oh! sorry for forgetting this (again). I'll try to release tonight. |
Sorry, I need to rewrite the release process to use the I'll have to rewrite |
I think the root problem was that gpg2 upgrade dropped my old key when it rewrote the I only figured that out after mostly getting the |
Released 2.8.1. Sorry for the delays! I think it takes ~20 min to promote from their staging to central repository. |
Maybe this will help somebody else since it was a maze of github issues and hibernate docs to figure out a working version of hibernate second level cache w/o a file named 'application.conf' (which, in a larger application is a pretty bad name since it is definitely not the application's primary config file). Thanks for this library. Been in production for years no major problems. private void enableSecondLevelCache(Map<String, Object> jpaProperties) {
// "inject" our config into caffeine's jcache provider
TypesafeConfigurator.setConfigSource(() ->
ConfigFactory.parseResources("hibernate-caches.conf",
ConfigParseOptions.defaults().setAllowMissing(false)));
jpaProperties.put("hibernate.cache.use_second_level_cache", "true");
jpaProperties.put("hibernate.cache.region.factory_class", "org.hibernate.cache.jcache.JCacheRegionFactory");
jpaProperties.put("hibernate.javax.cache.provider", "com.github.benmanes.caffeine.jcache.spi.CaffeineCachingProvider");
jpaProperties.put("hibernate.javax.cache.missing_cache_strategy", "fail");
jpaProperties.put("hibernate.cache.use_query_cache", "true");
} |
Thanks! Another approach if you want to rename the default |
Working setup: microprofile framework, jcache-api, cache-annotations-ri-cdi, caffeine and typesafe config file.
We are using
microprofile-config
style configuration files and I would preferrably like to eliminate the typesafe'sapplication.conf
and instead read the JCache config from our own yaml file. Writing a mapper on framework bootstrap to do the conversion tocom.typesafe.config.Config
is easy enough but I am not sure how to programatically set this new config instance to caffeine.Any pointer in the right direction is welcome.
The text was updated successfully, but these errors were encountered: