Sep 2, 2014 at 9:58 AM
During the development of
Orchard App Host
some ideas came up that could be implemented in the core. Let me know what you think:
- Modify RawThemeExtensionLoader and CoreExtensionLoader as in
AppHostCoreExtensionLoader to allow loading of extensions not just from e.g. ~/Core but also Anything/Core too.
- Less Web.config/XML configuration: e.g log4net configuration. More code configuration in an extensible way; if XML configuration is inevitable, have a code configuration extension point where one implementation reads a configuration file.
- CommandHostVirtualPathMonitor as a public type (can be abtract to avoid automatic Autofac registration)
- External context for OrchardHost: DefaultOrchardHost (in the end) uses either HttpContext.Current or CallContext to carry information between StartRequest() and EndRequest(), and DefaultProcessingEngine uses the same technique. If there is no HttpContext
present and the code between StartRequest() and EndRequest() switches threads (what happens when using async-await for example) then this causes the context to get lost (e.g. modified shells won’t be restarted).
To mitigate this OrchardHost could enable the optional usage of an externally fed context object (added through BeginRequest for example).
A similar issue is present with WorkContextAccessor (see: