Class SystemTextJsonSerializerRegistry

Namespace

Quartz.Serialization.SystemTextJson

Assembly

Quartz.dll

The trigger and calendar serializers a SystemTextJsonObjectSerializer knows about.

public sealed class SystemTextJsonSerializerRegistry

Inheritance

object

SystemTextJsonSerializerRegistry

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.ReferenceEquals(object, object)

object.ToString()

Remarks

A new instance already knows every trigger and calendar type Quartz ships with, so registering a custom one adds to that set rather than replacing it.

These registrations used to live in process-global dictionaries inside the converters, which meant two schedulers in one process could not serialize different custom types — whichever registered last won, silently. Owning them per instance is what makes the choice belong to the scheduler that made it. Registrations are expected to be complete before the owning serializer is initialized; the maps are not synchronized for concurrent writes, exactly as the statics they replace were not.

A registry is also where the serializer's JsonSerializerOptions get the metadata a trimmed or native-AOT application has instead of reflection. It answers for every trigger and calendar type registered with it, built-in or custom, because AddTriggerSerializer<TTrigger>(ITriggerSerializer) and AddCalendarSerializer<TCalendar>(CalendarSerializer<TCalendar>) know the type statically; anything else the application puts in a JobDataMap is what AddTypeInfoResolver(IJsonTypeInfoResolver) is for.

Constructors

SystemTextJsonSerializerRegistry()

Creates a registry holding the serializers for the built-in trigger and calendar types.

public SystemTextJsonSerializerRegistry()

Methods

AddCalendarSerializer<TCalendar>(CalendarSerializer<TCalendar>)

Adds a serializer for a custom calendar type.

public SystemTextJsonSerializerRegistry AddCalendarSerializer<TCalendar>(CalendarSerializer<TCalendar> serializer) where TCalendar : ICalendar

Parameters

serializer CalendarSerializer<TCalendar>

Returns

SystemTextJsonSerializerRegistry

Type Parameters

TCalendar

Remarks

The serializer is the typed CalendarSerializer<TCalendar> for this very calendar, so a mismatched pairing is a compile error rather than an InvalidCastException on the first calendar that round-trips. TCalendar is inferred from the argument, so the type argument can be left off.

AddTriggerSerializer<TTrigger>(ITriggerSerializer)

Adds a serializer for a custom trigger type.

public SystemTextJsonSerializerRegistry AddTriggerSerializer<TTrigger>(ITriggerSerializer serializer) where TTrigger : ITrigger

Parameters

serializer ITriggerSerializer

Returns

SystemTextJsonSerializerRegistry

Type Parameters

TTrigger

AddTypeInfoResolver(IJsonTypeInfoResolver)

Adds the metadata for the application's own job-data value types, needed only where reflection-based serialization is off.

public SystemTextJsonSerializerRegistry AddTypeInfoResolver(IJsonTypeInfoResolver resolver)

Parameters

resolver IJsonTypeInfoResolver

A JsonSerializerContext the application generated — a partial class deriving from it with a [JsonSerializable] attribute per type — or any other IJsonTypeInfoResolver. Its Default instance is what to hand in.

Returns

SystemTextJsonSerializerRegistry

Remarks

A JobDataMap holds whatever the application put in it, so the store format has an open half no contract of Quartz's can close. With reflection on — every test host, every untrimmed application — that half is answered by reflection and this method is unnecessary. A PublishTrimmed or PublishAot application has no reflection to fall back to, and a value type Quartz cannot name reaches the writer as a NotSupportedException naming it. This is how the application answers for it.

Custom trigger and calendar types need nothing here: AddTriggerSerializer<TTrigger>(ITriggerSerializer) and AddCalendarSerializer<TCalendar>(CalendarSerializer<TCalendar>) know the type statically, so the registry already answers for them.

Resolvers are asked in the order they were added, behind Quartz's own contract and in front of reflection. A resolver that does not know a type returns nothing and the next one is asked, so handing in a context that names a type Quartz already covers changes nothing.