change the name of application.conf

[elba02md]

Hello,
I used Ceffeine as a second level cache provider with Hibernate for a spring boot app.
The issue is when I change the name of conf file (spring.jpa.hibernate.javax.cache.uri=application.conf to another-name.conf) this file is not considered.
I want to use a different name to avoid confusion with application.properties
So my question, do the name application.conf is mandatory ?

Thanks in advance .

[ben-manes]

You can set the strategy for how we load the configuration explicitly in TypesafeConfigurator.setConfigSource(Supplier<Config>) .

Otherwise, please see the documentation for the configuration library. Their general approach might require using the replacement system property (e.g. config.file) to avoid conflicts.

[ben-manes]

Looking around and I am not familiar with the javax.cache.uri setting. It looks to be custom and added by the Ehcache authors, but I haven't dug in much yet. We probably could mirror the behavior if you think that would be helpful for others.

[ben-manes]

It does seem this was an oversight / misunderstanding on my part as the jsr spec authors use the uri as a configuration source in their implementations. The reference implementation and spec documentation only specify it as a lookup qualifier, so I didn't realize this behavior. I think we can follow their examples of trying to resolve through the URI if set, else falling back to our default (configSource) if not found / compatible (mirroring Infinispan's logic linked below).

• Ehcache3
• Infinispan
• Hazelcast
• Coherence

[elba02md]

Thanks for your replies
you mean that method
private void activate() {
isOsgiComponent = true;
TypesafeConfigurator.setConfigSource(() -> ConfigFactory.load(DEFAULT_CLASS_LOADER));
}
where do you suggest to use this code TypesafeConfigurator.setConfigSource(() -> ConfigFactory.load("name-file.conf))?
when I use it during CacheManager bean creation, it's not considered and Hibernate keep using default file.

[ben-manes]

I would expect that it needs to be prior to the cache manager being initialized. That activate method should only be called if you are using OSGi which introduces its framework quirks, but you could add a debug point to see if your application invokes it. I'd try to make that config source change prior to hibernate as early as feasible, since JCache uses static singletons and is not designed towards dependency injection.

[elba02md]

Hibernate-jcache creates and initializes a cacheManager with default config before my cacheManager bean was created.
What I used to fix issue look like without effect
@bean
public CacheManager cacheManager() {
TypesafeConfigurator.setConfigSource(() ->
ConfigFactory.parseResources("cafeine-hibernate.conf",
ConfigParseOptions.defaults().setAllowMissing(false)));
javax.cache.CacheManager cacheManager= Caching.getCachingProvider().getCacheManager();
return new JCacheCacheManager(cacheManager);
}

[ben-manes]

Can you use some type of startup service that runs before hibernate is initialized? Even just a static block early in the application startup is enough, I suppose. I believe hibernate is calling into jcache itself rather than via Spring's support, so you need to set it early on like when the logger, connection pool, ect are being configured. It has been a decade since I used spring, but I remember setting initialization order by adding the xml equivalent to @DependsOn if my googling is right...

[elba02md]

I added a static block in the main class and that works
that might helps others, here is the code:
@SpringBootApplication
public class MainApplication {
public static void main(String[] args) {
SpringApplication.run(MainApplication .class, args);
}
static {
TypesafeConfigurator.setConfigSource(() ->
ConfigFactory.load("caffeine-hibernate"));
}
}
thanks again for your time :)

[ben-manes]

Is there any chance you could provide a sample project that uses your original attempt or point me to a reference that I can use? I have implemented the feature and it would be nice to have an end-to-end test to verify with.

The other vendors use URL.openConnection() which lets one use any registered scheme (file, https, rmi, s3, etc). That is a larger security loophole than I think is reasonable to allow, so for now I'd like to restrict it to a file / classpath resource. Then if someone does need a remote resource then they can supply their own configSource strategy.

[ben-manes]

I figured it out and created an example for future reference. It uncovered a small mistake where I had forgotten to handle fallbacks, which made the override less useful.

[ben-manes]

Released in 3.1.5