AOT: skip HOCON-based Type loading for default implementations

[Aaronontheweb]

Consider the following:

akka.net/src/core/Akka/Actor/Settings.cs

Lines 96 to 100 in 61bdebf

	var providerType = Type.GetType(ProviderClass);
	if (providerType == null)
	throw new ConfigurationException($"'akka.actor.provider' is not a valid type name : '{ProviderClass}'");
	if (!typeof(IActorRefProvider).IsAssignableFrom(providerType))
	throw new ConfigurationException($"'akka.actor.provider' is not a valid actor ref provider: '{ProviderClass}'");

This creates a problem for AOT'd applications because of the type loading across assemblies, which is verbotten under AOT compilation rules. For these types of issues, we have to refer users to the configuration sources such as our Setup classes (which use direct references, not assembly loading - and therefore is kosher.)

But for other cases, such as:

Default Log Formatter

akka.net/src/core/Akka/Actor/Settings.cs

Lines 166 to 170 in 61bdebf

	var logFormatType = Type.GetType(loggerFormatterName);
	if (logFormatType == null)
	throw new ArgumentException($"Could not load type of {loggerFormatterName} for ILogMessageFormatter.");
	if(!typeof(ILogMessageFormatter).IsAssignableFrom(logFormatType))
	throw new ArgumentException("Log formatter type must inherit from the ILogMessageFormatter interface.");

STD Out Logger

akka.net/src/core/Akka/Actor/Settings.cs

Lines 134 to 138 in 61bdebf

	var stdoutLoggerType = Type.GetType(stdoutClassName);
	if (stdoutLoggerType == null)
	throw new ArgumentException($"Could not load type of {stdoutClassName} for standard out logger.");
	if(!typeof(MinimalLogger).IsAssignableFrom(stdoutLoggerType))
	throw new ArgumentException("Standard out logger type must inherit from the MinimalLogger abstract class.");

Mailboxes

akka.net/src/core/Akka/Dispatch/Mailboxes.cs

Lines 62 to 75 in 61bdebf

	var requirements = mailboxConfig.GetConfig("requirements").AsEnumerable().ToList();
	_mailboxBindings = new Dictionary<Type, string>();
	foreach (var kvp in requirements)
	{
	var type = Type.GetType(kvp.Key);
	if (type == null)
	{
	Warn($"Mailbox Requirement mapping [{kvp.Key}] is not an actual type");
	continue;
	}
	_mailboxBindings.Add(type, kvp.Value.GetString());
	}
	_defaultMailboxConfig = Settings.Config.GetConfig(DefaultMailboxId);

Scheduler

akka.net/src/core/Akka/Actor/Internal/ActorSystemImpl.cs

Lines 283 to 286 in 61bdebf

	private void ConfigureScheduler()
	{
	var schedulerType = Type.GetType(_settings.SchedulerClass, true);
	_scheduler = (IScheduler) Activator.CreateInstance(schedulerType, _settings.Config, Log);

Dispatchers

Dispatchers are an example of where we already implement "the fix" I'm going to suggest for making Akka.NET's configuration system more AOT-friendly - skipping reflection and resolving known types when we know the HOCON matches a type that is already part of the core Akka assembly:

akka.net/src/core/Akka/Dispatch/Dispatchers.cs

Lines 587 to 616 in 61bdebf

	switch (type)
	{
	case "Dispatcher":
	dispatcher = new DispatcherConfigurator(cfg, Prerequisites);
	break;
	case "TaskDispatcher":
	dispatcher = new DispatcherConfigurator(TaskExecutorConfig.WithFallback(cfg), Prerequisites);
	break;
	case "PinnedDispatcher":
	dispatcher = new PinnedDispatcherConfigurator(cfg, Prerequisites);
	break;
	case "ForkJoinDispatcher":
	dispatcher = new DispatcherConfigurator(ForkJoinExecutorConfig.WithFallback(cfg), Prerequisites);
	break;
	case "SynchronizedDispatcher":
	dispatcher = new CurrentSynchronizationContextDispatcherConfigurator(cfg, Prerequisites);
	break;
	case null:
	throw new ConfigurationException($"Could not resolve dispatcher for path {id}. type is null");
	default:
	Type dispatcherType = Type.GetType(type);
	if (dispatcherType == null)
	{
	throw new ConfigurationException($"Could not resolve dispatcher type {type} for path {id}");
	}
	dispatcher =
	(MessageDispatcherConfigurator)Activator.CreateInstance(dispatcherType, cfg, Prerequisites);
	break;
	}

Custom Mailboxes, Dispatchers, Etc

Doing AOT with customizable components like a user-defined Mailbox or Dispatcher configuration is going to be more challenging. If Akka.Hosting is still AOT-friendly (which I assume it is, beyond the parts of core Akka that are not) then we could probably introduce some custom Setup classes that allow these types to be passed in by reference rather than dynamically loaded from an assembly. That will likely need to be a second phase of AOT support after the core library is cleaned up.