AI OnAI Off
ContentApiModelFilter is an internal class, while you can use it you shouldn't. Instead rely on IContentApiModelFilter.
I've posted an example implementation here https://world.optimizely.com/forum/developer-forum/Developer-to-developer/Thread-Container/2024/2/what-is-the-best-way-to-add-new-properties-to-the-response-of-the-content-delivery-api/
This can be registered into DI with any lifetime manager that may suit your needs
eg services.AddSingleton<IContentApiModelFilter, PageBaseFilter>();
Hello,
i have a serious issue with dependency injection of ContentApiModelFilters. It seems that it's always using a singleton no matter what lifecycle you use.
We have many filters and all behave as if ServiceInstance.Singleton was used. For example:
So the issue is that we always use the same instance of the fields used via constructor injetion. The ContentResolver for example is responsible to resolve content for a given url(using IUrlResolver.Route). But since we cache that value we always get the same content once it was resolved, on any page.
Why is it so, are the filters used in a singleton context by episerver?
It also does not make a difference if i register it by myself:
Is the only solution to use a workaround like not using constructor injection at all but always use the ServiceProvider?
Edit: Unfortunately it is not a solution to just implement IContentApiModelFilter instead of inheriting from ContentApiModelFilter<ContentApiModel> as Eric Herlitz has suggested. Even if you register it manually in Startup.cs via AddScoped you will have a singleton in the filter. The reason i could find out via reflection of the epi source code. ContentConvertingService is a singleton itself:
You either have to avoid a singleton in ContentConvertingService or find a way to resolve the filters without using constructor injection to fix this bug.