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 <[email protected]>
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: [email protected]
For additional commands, e-mail: [email protected]
