TimerSchedule creates TimerSchedule using System.Activator

[abatishchev]

TimerSchedule creates an instance of TimerSchedule using System.Activator(). And doesn't use IJobActivator what prevents dependency injection and deferring schedule configuration from compile time to runtime.

Theoretically Create() could accept an instance of IJobActivator but here another problem: it has only method T CreateInstance<T>() and doesn't have a non-generic overload such as object CreateInstance(Type type).

Is it something you would consider to review if I submit a pull request, please?

[christopheranderson]

This is an interesting idea. We'll help you review this as time allows, but it might need to wait to review and accept this after our 2.0.0 release, which is our current focus. Feel free to ask us any further questions.

[abatishchev]

hi @christopheranderson, can we come back to this idea, please?

[mathewc]

@abatishchev to address your ask, I think we'd have to spend time looking at our DI story all up, which is pretty bare bones at this point as others have pointed out / complained about. The IJobActivator interface is only for creating job classes - it isn't a general purpose factory for other types, so I don't think it would make sense here. That's why it doesn't have the Type overload as you pointed to above.

To solve this correctly we'd likely introduce a new mechanism that generalizes and subsumes the old IJobActivator functionality, or we would introduce breaking changes to IJobActivator. This didn't meet the bar for 2.0 - we had to get that release out.

[mathewc]

https://github.com/Azure/azure-webjobs-sdk/issues/1036

[abatishchev]

thanks for in insight! I just was hoping that this breaking change suits 2.0 well

[abatishchev]

@mathewc hi, should we come back to this idea? Or give up and close?