You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@druid.apache.org by gi...@apache.org on 2021/11/24 01:04:06 UTC
[druid] branch master updated: Update LifecycleModule.java (#11972)
This is an automated email from the ASF dual-hosted git repository.
gian pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/druid.git
The following commit(s) were added to refs/heads/master by this push:
new e6570ca Update LifecycleModule.java (#11972)
e6570ca is described below
commit e6570cadc4eee13b450810b26d24bb52944829d0
Author: cheddar <ch...@users.noreply.github.com>
AuthorDate: Tue Nov 23 17:03:37 2021 -0800
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.
---
.../org/apache/druid/guice/LifecycleModule.java | 25 +++++++++++++++-------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/core/src/main/java/org/apache/druid/guice/LifecycleModule.java b/core/src/main/java/org/apache/druid/guice/LifecycleModule.java
index a793d4a..695b5ee 100644
--- a/core/src/main/java/org/apache/druid/guice/LifecycleModule.java
+++ b/core/src/main/java/org/apache/druid/guice/LifecycleModule.java
@@ -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
*/
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org