-
Notifications
You must be signed in to change notification settings - Fork 322
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
AddEasyCaching access to IServiceProvider - Redis Services are resolved at runtime via another Service #273
Comments
An additional path here is that we're already using the Would there be a possible future alternate configuration approach where we can use a variation of the |
@Simonl9l Thanks for your interest in this project. We will take a look ASAP. |
@catcherwong thanks! very impressed by what we see with this in conjunction with the EF Core Second Level Cache Interceptor so all help greatly appreciated! |
@catcherwong hi - any word on when this might be addressed? |
@Simonl9l I'm very sorry, I don't have enough time to deal with this issue right now. |
@catcherwong OK - do please let us know what you do have enough "ASAP" time to take a look... |
If your Redis endpoints are discoverable via a service registry, you can do something combine service registry and |
I am not sure |
@catcherwong thanks for the followup - per my code above, the endpoints are not available from configuration but via another service call to a registry service implementation (that makes HTTP calls via an The challenge is with the startup service configuration code in that we have a chicken-egg problem, that until the services container is built and made accessible via an The can't is more one should not by best practice call By making the As I understand it, when the service provider is built and all the available services are registered, that when a given service is requested the first time, that services configuration function is executed. Any dependent services will be identified by the service container as they are also retrieved - or others DI'd - and as applicable their startup function will each be executed first. Whist I have something that works it's not ideal. With out the services.AddEasyCaching(option =>
{
var endpoints = services.BuildServiceProvider().GetRequiredService<RedisEndpoints>().Endpoints;
option.UseRedis(config =>
{
config.DBConfig.AllowAdmin = true;
endpoints.ForEach(endpoint => config.DBConfig.Endpoints.Add(new ServerEndPoint(endpoint.Host, endpoint.Port)));
}, providerName);
}); where the Does this explain the needs better - just trying to use dotnet core service registration as designed...? |
This comment has been minimized.
This comment has been minimized.
Just a bump on this thread, having a mechanism to access |
Hi - We're trying to use the caching in an environment were the Redis endpoints are discoverable via a service registry (consul). It would be great if the
AddEasyCaching
configuration action had access to the service provider.Do you have any recommendation to best active this with what is available today, given that the service (per
RedisEndpoints
) below is registered elsewhere, and it being not best practice to cal'BuildServiceProvider()
directly.The EF Core DBContext
AddDBContext
service extension for configuration as an example does provide access to the service provider,It would be great if in future versions I could do something like the following:
The text was updated successfully, but these errors were encountered: