ServiceRegistry is used to allow a given application access to application
Services are typically registered or requested using an alias name, but older applications may still register and request using interfaces, which is also still supported. Applications that use aliases don't normally need to manually register services as these are created lazily upon first request, but will still need to manually register services that can't be created using a zero-arg constructor.
ServiceRegistry is initialized as follows:
- The application invokes
module:ct-core/ServiceRegistry.initializeServiceswhich causes all delayed readiness services to be created.
module:ct-core/ServiceRegistry.initializeServiceshas finished (once one of the call-backs fire), the application should then register any services that can't be created lazily using zero-arg constructors.
- The application can now start doing it's proper work.
Because blades aren't allowed to depend directly on classes in other blades, interface
definitions are instead created for particular pieces of functionality, and blades can choose
to register themselves as being providers of that functionality. The
ServiceRegistry and the
module:ct-core/event/EventHub are both useful in this
- Many-To-One dependencies are resolved by having a single service instance available via
- Many-To-Many dependencies are resolved by having zero or more classes register with the
ServiceRegistry is a static class and does not need to be constructed.
Registering with this method will notify when all services that implement
are ready to use.
the function that is called back when all services implementing
the function that is called back if there is an error during initialisation of any of the services, a string reason will be passed in as argument.
if this method is called more than once.