Apache
/
druid
mirror of https://github.com/apache/druid.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update LifecycleModule.java (#11972) 

Update the javadoc on LifecycleModule to be more clear about why the register methods exist and why they should always be used instead of Guice's eager instantiation.
This commit is contained in:
cheddar 2021-11-23 17:03:37 -08:00 committed by GitHub
parent b6a0fbc8b6
commit e6570cadc4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 17 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
core/src/main/java/org/apache/druid/guice/LifecycleModule.java
View File

@ -57,8 +57,11 @@ public class LifecycleModule implements Module
*
* This mechanism exists to allow the {@link Lifecycle} to be the primary entry point from the injector, not to
* auto-register things with the {@link Lifecycle}. It is also possible to just bind things eagerly with Guice,
* it is not clear which is actually the best approach. This is more explicit, but eager bindings inside of modules
* is less error-prone.
* but that is almost never the correct option. Guice eager bindings are pre-instantiated before the object graph
* is materialized and injected, meaning that objects are not actually instantiated in dependency order.
* Registering with the LifecyceModule, on the other hand, will instantiate the objects after the normal object
* graph has already been instantiated, meaning that objects will be created in dependency order and this will
* only actually instantiate something that wasn't actually dependend upon.
*
* @param clazz the class to instantiate
* @return this, for chaining.
@ -78,8 +81,11 @@ public class LifecycleModule implements Module
*
* This mechanism exists to allow the {@link Lifecycle} to be the primary entry point from the injector, not to
* auto-register things with the {@link Lifecycle}. It is also possible to just bind things eagerly with Guice,
* it is not clear which is actually the best approach. This is more explicit, but eager bindings inside of modules
* is less error-prone.
* but that is almost never the correct option. Guice eager bindings are pre-instantiated before the object graph
* is materialized and injected, meaning that objects are not actually instantiated in dependency order.
* Registering with the LifecyceModule, on the other hand, will instantiate the objects after the normal object
* graph has already been instantiated, meaning that objects will be created in dependency order and this will
* only actually instantiate something that wasn't actually dependend upon.
*
* @param clazz the class to instantiate
* @param annotation The annotation class to register with Guice
@ -98,10 +104,13 @@ public class LifecycleModule implements Module
* scope. That is, they are generally eagerly loaded because the loading operation will produce some beneficial
* side-effect even if nothing actually directly depends on the instance.
*
* This mechanism exists to allow the {@link Lifecycle} to be the primary entry point
* from the injector, not to auto-register things with the {@link Lifecycle}. It is
* also possible to just bind things eagerly with Guice, it is not clear which is actually the best approach.
* This is more explicit, but eager bindings inside of modules is less error-prone.
* This mechanism exists to allow the {@link Lifecycle} to be the primary entry point from the injector, not to
* auto-register things with the {@link Lifecycle}. It is also possible to just bind things eagerly with Guice,
* but that is almost never the correct option. Guice eager bindings are pre-instantiated before the object graph
* is materialized and injected, meaning that objects are not actually instantiated in dependency order.
* Registering with the LifecyceModule, on the other hand, will instantiate the objects after the normal object
* graph has already been instantiated, meaning that objects will be created in dependency order and this will
* only actually instantiate something that wasn't actually dependend upon.
*
* @param key The key to use in finding the DruidNode instance
*/