IIRC, it was consciously not changed in Kernel.

@fabpot Do you remember for what reason?

@xabbuh I'm not sure but @mpdude might remember.

ConfigCacheFactory can be used for service based cache validation (doc PR still pending). That does not make sense for the container if you need the contained services to validate it... Or would it?

I found this in the PR description of #14178:

Component/HttpKernel/Kernel::initializeContainer still uses the ConfigCache implementation directly as there is no sensible way of getting/injecting a factory service (chicken-egg).

I don't think that this is true. For example, one might want to customise this steps by providing a custom ConfigCacheFactoryInterface implementation in their AppKernel class.

@mpdude What do you think?

Well, technically it should work in a straightforward manner.

It's probably tedious to set up in the AppKernel when you don't have services or the DIC.

All real life use cases I've seen so far involved loading routes or translations from a database and I have no idea if that might make sense for the Kernel as well.

So, is this just a consistency thing or do you have a real use case where it would help? If so, do you want to change the way the container is cached or the way that cache is validated?

I would err on the side of not "fixing" this in the Kernel... except if someone does have a real world use case.

For now, this is more a consistency thing, which @aitboudad and I talked about, but I don't have a concrete use case in mind and AFAIK neither does he. So, of you think it's not wish to do this change just for the same if consistency, let's see if someone comes up with a real use case or close it otherwise.

I'm in favor of closing this. There is no point in providing an extension point if we don't have a use case.

@fabpot what do you think about using ConfigCacheFactory here without providing an extension point, which is consistent and better than using ConfigCache directly ?

Honestly I don't see any use case even for translations or routes, the current implementation is mainly related to locale files and it's not possible to loading from a database for example.

@aitboudad See #14178 and the related PRs.

The ConfigCacheFactory does not directly provide the loading from (for example) a database. You'd have to write your own loaded for that.

The thing is that once your data has been pulled from the DB and is put into ConfigCache, you have no way of re-validating that cache and to check if the cached content is still in sync with the database. This is because all the cache validation happens inside the ConfigCache class which was previously created inside the Translator (for example). No way of getting any other validation logic in there, especially one that would need access to a DB. Being able to inject the ConfigCacheFactory changed that.

@mpdude thanks for the clarification :)
If I understand, the need here is to check the cache is still sync or not, so why not just using custom ResourceInterface.
If we talk about Translator (for example) the consistant way is to use a custom loader (loading from database) and when data is loaded we can add then add Resource to the Catalogue to check data freshness from DB.

Anyway I think I missed something so I prefer to stay until this part is documented ^^

Yes, I know, writing the docs is on my list. A custom ResourceInterface implementation does not work, because the Resource is simply unserialized from the cache and isFresh() is called. No way to get a database connection in there.

Can we close this PR for the time being?

Closing now.