No longer able to use custom getters and setters through ContentD

No longer able to use custom getters and setters through ContentDataInterceptorHandler for specific block property types?

Ted

Vote:

I've been using site-wide custom getters and setters through ContentDataInterceptorHandler for specific block types, used as property types, using something like the following in an initialization module with a dependency to EPiServer.Web.InitializationModule:

var contentDataInterceptorHandler = ServiceLocator.Current.GetInstance<ContentDataInterceptorHandler>();

contentDataInterceptorHandler.For<PropertyBlock<MyBlockType>>().Use<MyBlockType>(MyBlockTypeGetter, MyBlockTypeSetter);

However, in later CMS versions (I think sometime after 11.18) this no longer seems to work.

Is anyone aware of any changes that would break this?

#230647

Edited, Nov 10, 2020 15:49

Eric Herlitz - Nov 10, 2020 21:09

Which version of Episerver.Cms.Core are you using?

Ted - Nov 11, 2020 8:01

11.20.1

Ted - Nov 11, 2020 13:57

I have verified everything works fine in 11.15.1, but breaks after upgrading to 11.20.1.

Eric Herlitz - Nov 11, 2020 14:23

There is nothing obvious to me in the release when filtering the release notes from 11.16 to 11.20 https://world.episerver.com/documentation/Release-Notes/. I did read something about changes in StructureMap and ServiceLocator registrations in breaking changes but cannot find the reference to that at the moment.

Ted - Nov 11, 2020 14:36

Thanks! Please let me know if you find any info on that breaking change, I couldn't find it either. I'm only aware of the breaking change in CMS 11 when certain StructureMap features were separated into a separate NuGet package. I'm not using any StructureMap features explicitly, however.

Mark Everard

Vote:

Likely related to this Ted?

https://world.episerver.com/documentation/Release-Notes/ReleaseNote/?releaseNoteId=CMS-15856

#230701

Nov 11, 2020 21:51

henriknystrom

Vote:

It's very likely related to the new high performance IL generation as pointed out by Mark.

We have tried to detect when any property interceptor has been registered and in those cases fall back to the old Castle based IL to prevent any breaking changes. But there are many different ways to register such interceptors, and it seems like we may have missed your case.

You can try and disable the new proxy manually by setting the ProxyType value on ContentOptions to ProxyType.Castle. You probably know this, but it can be done in your configurable initialization module through a call such as:

public void ConfigureContainer(ServiceConfigurationContext context)
{
    context.Services.Configure<ContentOptions>(x => x.ProxyType == ProxyType.Castle);
}

#230703

Edited, Nov 11, 2020 22:07

Johan Björnfot

Vote:

As Henrik said there is an intention that we should detect custom registrations of castle interceptors and if so use castle fro proxy generation. But apparently we fail to detect for some registrations. I have created an issue for this CMS-17430.

Thanks for the feedback and sorry for the inconvenience.

#230730

Nov 12, 2020 6:48

Ted

Vote:

Thanks for your quick help, guys! Highly appreciate it!

Explicitly setting the proxy type to Castle did restore the old behavior. We'll use that as a workaround for now and keep track of CMS-17430.

Are there any plans to introduce a different way of registering custom property interceptors (or something else to that effect)?

Thanks again!

#230735

Nov 12, 2020 8:56

Try our conversational search powered by Generative AI!

No longer able to use custom getters and setters through ContentDataInterceptorHandler for specific block property types?