Re: Issue 62 in google-guice: Lifecycle support
Comment #118 on issue 62 by mark.a...@gmail.com: Lifecycle support https://code.google.com/p/google-guice/issues/detail?id=62 This issue has been open since 2007 Really? If you need life-cycle management and more responsive developers consider using HK2. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To unsubscribe from this group and stop receiving emails from it, send an email to google-guice-dev+unsubscr...@googlegroups.com. To post to this group, send email to google-guice-dev@googlegroups.com. Visit this group at http://groups.google.com/group/google-guice-dev. For more options, visit https://groups.google.com/d/optout.
Re: Issue 62 in google-guice: Lifecycle support
Updates: Status: MigratedToGitHub Comment #119 on issue 62 by sberlin: Lifecycle support https://code.google.com/p/google-guice/issues/detail?id=62 The code.google.com guice project has migrated to GitHub. This issue site is no longer being used. Please use https://github.com/google/guice/issues/62 instead. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To unsubscribe from this group and stop receiving emails from it, send an email to google-guice-dev+unsubscr...@googlegroups.com. To post to this group, send email to google-guice-dev@googlegroups.com. Visit this group at http://groups.google.com/group/google-guice-dev. For more options, visit https://groups.google.com/d/optout.
Re: Issue 62 in google-guice: Lifecycle support
Comment #116 on issue 62 by b.k.ox...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 +1 This would be great simple functionality to fold into Guice. Lifegycle uses a simple type listener module to implement, so the is optional. Simply supporting @PostConstruct and @PreDestroy is 90+% of what I need in some of my projects. Presently we depend on Spring; I would love to migrate to Guice for these. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To unsubscribe from this group and stop receiving emails from it, send an email to google-guice-dev+unsubscr...@googlegroups.com. To post to this group, send email to google-guice-dev@googlegroups.com. Visit this group at http://groups.google.com/group/google-guice-dev. For more options, visit https://groups.google.com/groups/opt_out.
Re: Issue 62 in google-guice: Lifecycle support
Comment #117 on issue 62 by b.k.ox...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 This would be great simple functionality to fold into Guice. Lifegycle uses a simple type listener module to implement, so the is optional, a good candidate for guice extensions. Simply supporting @PostConstruct and @PreDestroy is 90+% of what I need in some of my projects. Presently we depend on Spring; I would love to migrate to Guice for these. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To unsubscribe from this group and stop receiving emails from it, send an email to google-guice-dev+unsubscr...@googlegroups.com. To post to this group, send email to google-guice-dev@googlegroups.com. Visit this group at http://groups.google.com/group/google-guice-dev. For more options, visit https://groups.google.com/groups/opt_out.
Re: Issue 62 in google-guice: Lifecycle support
Comment #114 on issue 62 by mccu...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 GIN only uses Guice at compile time, so additional work is required to support extensions - for example, assistedinject and multibinder have both been adapted in GIN (but the API/design is based on the original extension). See the various submodules under http://code.google.com/p/google-gin/source/browse/#svn%2Ftrunk%2Fsrc%2Fcom%2Fgoogle%2Fgwt%2Finject%2Fclient So while the API and code to support lifecycles is available, it will need to be adapted for GIN. Whether this is done by porting and re-implementing the underlying TypeListener/ProvisionListener API on top of GIN's GWT runtime, or by looking at lifegycle's higher-level design and porting that, is a question for the GIN folks. (PS. the original home for lifegycle was http://99soft.github.io/lifegycle/ before it moved to Apache/Onami) -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To unsubscribe from this group and stop receiving emails from it, send an email to google-guice-dev+unsubscr...@googlegroups.com. To post to this group, send email to google-guice-dev@googlegroups.com. Visit this group at http://groups.google.com/group/google-guice-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Issue 62 in google-guice: Lifecycle support
Comment #110 on issue 62 by davide.cavestro: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Please note this is blocking even GWT/GIN @PostConstruct annotation implementation. For GIN there's not 3rd party plugins available providing this kind of features, and GIN guys are waiting for this guice feature in order to introduce some useful features. GIN issue tracker ref: http://code.google.com/p/google-gin/issues/detail?id=176 -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To unsubscribe from this group and stop receiving emails from it, send an email to google-guice-dev+unsubscr...@googlegroups.com. To post to this group, send email to google-guice-dev@googlegroups.com. Visit this group at http://groups.google.com/group/google-guice-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Issue 62 in google-guice: Lifecycle support
Comment #111 on issue 62 by gok...@google.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Clarification: I said I don't see this [@PostConstruct] being added without Guice chooses to do so. We might end up having extensions points some time in the future and then one can write extension similar to that - but that is a different story... -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To unsubscribe from this group and stop receiving emails from it, send an email to google-guice-dev+unsubscr...@googlegroups.com. To post to this group, send email to google-guice-dev@googlegroups.com. Visit this group at http://groups.google.com/group/google-guice-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Issue 62 in google-guice: Lifecycle support
Comment #109 on issue 62 by antony.s...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 You guys might want to look at GuiceBox's @Stop annotation... -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Updates: Status: Acknowledged Labels: Component-NewExtension Comment #108 on issue 62 by cgruberatg...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Unclear whether this needs to be in core, or can be fully expressed in an extension, but if it is to be, we need to expand the SPI to support it, as I think it would incur a cost on those who didn't need it if it were in core. For now, I'm putting this into a New component in the issues, as we figure out how best to do this. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #104 on issue 62 by noctarius...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 A nice concept but isn't this the first step to make Guice a second Spring? Guice wasn't designed as an application framework, I'm not sure if it would be good to get that way. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #105 on issue 62 by noctarius...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 A nice concept but isn't this the first step to make Guice a second Spring? Guice wasn't designed as an application framework, I'm not sure if it would be good to go that way. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #106 on issue 62 by march...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Using a marker interface or annotations makes no great difference to me. I think that the reason why people (including me) request this feature is because it provides a simple machinery to forward the scope begin / scope end events to objects in that scope without requiring any dependency among who starts/stops the scopes and the object living there. Following this view, I think that it would make sense to generalize the eagerness attribute to each scope: instead of bind(X).to(Y).asEagerSingleton(), one could use something like bind(X).toY().eager().in(Singleton.class). In this way one could perform some initialization phase at (session / request / whatever ) start time. I think that this extension would also make less arbitrary the choice of which objects Guice should starts and stop. The user could force an object to be initialized (and destroyed) by Guice at scope beginning (end) simply by binding it eagerly in that scope. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #107 on issue 62 by cow...@bbs.darktech.org: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Regarding annotations vs marker interfaces, why would you need to iterate over the methods? Wouldn't you only scan the class itself for an annotation (same as a marker interface)? -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Hey Bob - I definitely imagined lifecycle features on Guice as being an opt-in. In fact, I'd like to see a lot more of Guice decoupled so features that can be expensive are opt-in, or behavioural defaults can be opt-in. But certainly, lifecycle needs to be built with support/integration from Guice, but it could be layered on top, with hooks exposed. Regardless, yes - the performance impacts need to be evaluated in any solution. And real use-cases are definitely what we want to work from. Christian. On Mar 14, 2012, at 1:08 AM, google-gu...@googlecode.com wrote: Comment #73 on issue 62 by crazybob...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 This issue is still open? :-) I'd recommend against adding a sophisticated service lifecycle management framework to Guice. This could be a framework in and of itself. Of course, such a framework could integrate with Guice. 5 years ago, I didn't want Guice to depend on @PostConstruct and @PreDestroy because this would have created a dependency from Guice on Java EE. This would have been unacceptable because core Guice needs to run on platforms like Android. Today, these annotations are part of core Java (since Java 6). Functionality that depends on these annotations could fail fast when the annotations aren't present (Java 5, Android, etc.). For example, Injector.shutDown() would throw a runtime exception. Simple support for @PostConstruct and @PreDestory might make since. It wouldn't make sense to support @PostConstruct alone. It exists because @Resource supports only fields and methods. Guice supports constructors and does not need something like @PostConstruct. However, if we support @PreDestroy, we should almost certainly support @PostConstruct, too, to avoid confusion. Do we need @PreDestroy support? If so, how exactly should it behave? What level of flexibility do we need with regard to concurrency (asynchronous, parallel), exception handling, invocation ordering, etc.? Does it apply to only objects instantiated by Guice or all objects? What's the compatibility story? To answer these questions, *we need concrete, real world use cases (examples) for @PreDestroy*. We need lots of examples, and in each case, @PreDestroy should be the best way of addressing that use case. Finally, when it comes to the implementation, we need to take care not to introduce performance regressions, even if that means making this an opt-in feature. Performance is already bad enough on Android. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #75 on issue 62 by crazybob...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 I wouldn't use Closeable (#1) here. It would be surprising to me if Guice called close() on my objects just because they happen to implement Closeable. Also, close doesn't fit all of the use cases. If anything, we'd support @PreDestroy, but again, what are the use cases? A looked through the first 20 or so pages of results on koders.com and didn't see one interesting usage. I can try to imagine some: 1. Closing I/O resources 2. Shutting down threads and executors 3. Proactively freeing native memory 4. Removing external references (listeners, etc.) ... @PreDestroy doesn't seem like a good solution to any of these. Use try-finally, try-with-resources, references, explicit shut down logic, etc., instead, and your code will be less error prone and more maintainable. No offense intended to Hani and others than were on JSR-250, but my sense is that @PreDestroy is an annotation in search of a problem. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #76 on issue 62 by h...@formicary.net: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 The usecase I have is mostly in getting rid of Providers. Basically, once everything is wired up (config) I want to then 'start stuff up', this includes making external connections based on bindings, and so on. It's a very good match for @PostConstruct. @PreDestroy I haven't used. I tend to prefer explicit demarcation lines to denote scope ends, rather than have it done for me. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #80 on issue 62 by kvas...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Services should start in the proper order - all dependencies should start before. Same for stop. So it's really close to dependency injection. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
It may not be dependency injection, but enabling an in-dependency-graph-order traversal of Services, and starting them each before anything it depends on, and parallizing startup - that seems like something that can benefit from the dependency graph. Yes, it's not in the scope of the core of Guice - dependency injection, but it's not just injection, it's dependency management - injection is the core (constructing with dependencies) but if a dependency needs to be both extant/present AND properly started, the thing that controls the wiring should be helping out here. On Mar 14, 2012, at 2:58 PM, google-gu...@googlecode.com wrote: Comment #80 on issue 62 by kvas...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Services should start in the proper order - all dependencies should start before. Same for stop. So it's really close to dependency injection. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #81 on issue 62 by kvas...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Telling the truth, I am really satisfied with mycilla guice. BUT guice defenitely should include bug fixes from #676. 1) Guice does not throw errors on null values in injected fields, but it should. 2) Singletons are recreated many many times even if error occurs. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #82 on issue 62 by h...@formicary.net: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Yes, I never use guice 'base', always go with mycilla instead. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #84 on issue 62 by franci...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Ain't this more about proper shutdown than startup? -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #85 on issue 62 by kvas...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Startup can be handled via constructors. This is really more about shutdown. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #86 on issue 62 by christia...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Ok - sorry - shutdown was the key part of this, but startup handled by constructors? That's really not ideal. I don't think I'm comfortable with THAT being the recommendation on how to do initialization of services with Guice. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #87 on issue 62 by mccu...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 FYI, it's been really easy to make a lifecycle extension now the ProvisionListener API has been added: http://code.google.com/p/google-guice/source/browse/core/src/com/google/inject/spi/ProvisionListener.java We use this to add Plexus lifecycle support (the classic Initializable/Startable/Disposable interfaces) https://github.com/sonatype/sisu/blob/master/sisu-inject/containers/guice-plexus/guice-plexus-lifecycles/src/main/java/org/sonatype/guice/plexus/lifecycles/PlexusLifecycleManager.java#L129 The great thing about ProvisionListener is that you can use it to track dependency chains, which helps you decide the starting order of components. Note: with Plexus you can't simply just start a component on the constructor call because of cycles (which exist in legacy code) and because components use a lot of field injection. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #88 on issue 62 by kvas...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Please, take a look on buf #676. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #89 on issue 62 by kvas...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Please, take a look on: http://code.google.com/p/google-guice/issues/detail?id=676 This bug is stop point when working with ProvisionListener for startup/shutdown. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #91 on issue 62 by mccu...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Re #676 our lifecycle support fails-fast so that hasn't been an issue for us, but I can see how it could affect others - can you perhaps add a testcase to demonstrate each scenario and verify the proposed fix? -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #92 on issue 62 by cow...@bbs.darktech.org: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Bob, I'm not suggesting that Closeable replace @PreDestroy. I'm saying: don't make us implement @PreDestroy for Closeable. Guice should provide this reasonable default behavior. What's the harm in auto-closing Closeable instances once their enclosing scope is destroyed? There is no harm in doing so because the specification explicitly states If the stream is already closed then invoking this method has no effect. Common use-case: Closing database connections (if necessary) to prevent leaks. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #93 on issue 62 by crazybob...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 What's the harm in auto-closing Closeable instances once their enclosing scope is destroyed? Maybe I don't want the object to be closed. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #95 on issue 62 by crazybob...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Sorry, cowwoc. Guice is explicit and not surprising. Someone maintaining your code and trying to figure out if/how a resource gets closed would no doubt be surprised to find out that Guice automagically does it for them. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #96 on issue 62 by crazybob...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 I think closing/destroying objects when they go out of scope is a red herring. It sounds like people really want the ability to start and stop per injector services in the right order. While the lifecycle of the service is the same as the injector's, the object isn't necessarily in singleton scope– maybe the service isn't eligible for injection into other objects (see Binder.requestInjection()). @PostConstruct and @PreDestroy seem like a bad fit here. First, they don't speak to starting and stopping services. Second, and less important than the naming and semantics, using annotations will be slower and more error prone than using a marker interface. How do we decide which objects are eligible to be started? Strawman: any object that's created or injected during injector creation. This includes eager singletons, objects passed to requestInjection(), and any transitive dependencies. Note: This could get a little weird if you use DEVELOPMENT vs. PRODUCTION stages. One could use an InjectionListener named ServiceManager to collect any object that implements Guava's Service interface. After injector creation, you call ServiceManager.start(). ServiceManager stops collecting objects (by ignoring any further callbacks), and then it iterates over the objects in the order in which they were created–so you can use dependencies to control the order services are started in–and it starts each service. When you're ready to stop, call ServiceManager.stop(). It'll stop the services in the reverse order. Once Guice supports concurrent singleton injection (by inspecting the dependency graphs), ServiceManager could keep track of which threads the callbacks come in on. Then it could make sure that objects instantiated in the same thread are also started in the same thread. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #97 on issue 62 by h...@formicary.net: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 So checking for a @PostConstruct is a performance hit when you're already going through all methods and fields checking for @Inject? Why is it any slower? The flow as I see it is, if guice creates an object, it is responsible, once the full object graphs has been constructed, for calling @PostConstruct. I don't see it getting weird with things like .injectMembers() and .requestInjection(), in those cases @PostConstruct would not apply because guice did not construct the object. Admittedly with stages it might get weird, but nothing that well specified behaviour cannot address. For a novice/beginner dev, there are plenty of non-intuitive and cryptic behaviours and features in Guice, but they're pretty well specified so it's not terrible. Keep in mind also that all this *is* possible. I have all the extra behaviour I'd like in Mycilla Guice. There's just some fundamental issue I must be misunderstanding as to why it's so unthinkable for Guice to get those features. The 'prove we need it argument' is not very compelling anymore, 100 comments and 5 years on from the initial request. I'd like to reverse the challenge, and ask for a non-core Guice developer to argue we absolutely should not have it! Clearly all arguments in favor of this feature are not ones that have resonated with any Guice developers, so just close it and say it'll never happen. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #98 on issue 62 by crazybob...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Iterating over methods and checking for an annotation is an order of complexity slower than instanceof Service, especially if you didn't already need to reflect on those methods. This is just to say that it would be nice to not force this overhead on Android apps. Why would we only start instances that Guice instantiated? Seems like an arbitrary limitation. To be fair, I think you're asking for something different from what everyone else is asking for. Other people want to start/stop services, orthogonally to injector creation. That makes some sense to me, but needs further specification. For example, which objects exactly are eligible to be started? You've said that you don't care about stopping things and you just want @PostConstruct. This does not make sense to me because @PostConstruct is barely different from a constructor. Also, if you just want @PostConstruct support, it's trivial to hook in with an InjectionListener already. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #99 on issue 62 by endre.st...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Quick question: Have Guice gotten intelligent about the order in which it instantiates objects? Earlier, it just did one or the other random order, not caring about each instance dependencies, creating those annoying proxies when it got to any dependency it didn't already have available. Then one got the option of specifying that proxies should not be used. However, the order hadn't gotten any smarter, so one still could arbitrarily crash into the ordering-problem, only now it stops with exception, not creating the proxy. This even though a simple reordering of the flow would have fixed it. First create the leafs; the ones without dependencies. Then work your way up: Create instances whose dependencies at this point be fulfilled. If you at some point iterate through the entire list of to be instantiated w/o instantiating any, then you have a dependency-loop. Loops are only evaluated by constructors. Fields and methods can always be injected afterwards. .. which leads to my point #1 about stuff like @PostConstruct.. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #100 on issue 62 by endre.st...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 You need @PostConstruct because that would only be invoked after ALL dependencies have been injected - both the constructor *and* field/methods. This because you might need some service of some injected instance to start up. And that instance was injected by means of field injection. No good with constructor startup then. Also, according to JCIP IIRC, one shall not leak unfinished objects. In a constructor, you could e.g. register yourself with the OnIncomingUserEventService, and *then* your object instantiation crashes with a NPE for some other reason. Therefore, thou shall not ever do startup stuff in a constructor. Only construct yourself, do not e.g. attach yourself to other object graphs. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #101 on issue 62 by endre.st...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 When you folks create features out of this request, please enable me to do custom initialization. I have always ended up in needing several initialization phases, not only a single @PostConstruct. What I've needed, is at least a now you've got all your dependencies and configuration, do your init code, and then a now you can do listener registration with each other. So my ideal solution to this is to get a list (preferably in instantiation order) so that I can invoke my different init methods on the relevant objects. This could be fetched by user code when the injector was finished setting up the entire graph (and have invoked @PostConstruct?) - and then the user could would do what life cycling it needs to do. What I currently do, is to have a LifeCycle service which instances can depend on. There is also the LifeCycled interface. The objects register with the LifeCycle service, either in constructor (which is bad according to JCIP), or in the method injecting the LifeCycle service (better). After injector is finished, I run through all the instances that have registered with the LifeCycle service, all of which shall implement the LifeCycled interface. I then invoke method phase1 on all objects, then method phase2 on all objects, etc. (On application shutdown, I have corresponding phase-destroy methods on the LifeCycled interface, which are invoked in the opposite order). -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #102 on issue 62 by noctarius...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 It would be nice to see some help in Guice to build a service framework but it isn't needed, since startup order of services could be possibly different from injection dependecy order. In my framework I made it something like Bob meantioned. I used an the InjectionListenr / ProvisionListener to collect services implementing the frameworks service interface and after injection finished the frameworks ServiceManager collects and orders the services startup dependencies, searches for postConstruct() handlers and finally calls the startup() method of every service. When the framework is shutting down first all services preDestroy() method is called and finally the destroy() method. Right after that point the ServiceManager and the Injector are destroyed. It was a bit tricky at some small points but that is more a problem of the framework, which can be sticked together from plugins (all have their own AbstractModule) and a plugin descriptor, not a Guice problem. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #103 on issue 62 by limpbiz...@gmail.com: Lifecycle support
http://code.google.com/p/google-guice/issues/detail?id=62
PROPOSAL 102.
Add an extension that uses Guava's Service interface, and that makes it
easy to bind services and start them.
Perhaps a basic service registration DSL:
class MyAppServiceModule extends ServiceModule {
public void configureServices() {
bindService(JettyService.class);
service(JettyService.class).dependsOn(ConnectionPoolService.class);
}
}
Plus a mechanism to start and stop services. This could track
user-specified service dependencies.
public static void main(String... args) {
Stopwatch stopwatch = new Stopwatch();
Injector injector = ...
logger.info(Injector creation took + stopwatch.elapsed());
stopwatch.reset();
ServiceManager serviceManager =
injector.getInstance(ServiceManager.class);
serviceManager.registerServiceFailureHandler(new ServiceFailureHandler() {
public void serviceFailed(Service service, Throwable failure) {
logger.log(WARNING, Service + service + failed; shutting down,
failure);
serviceManager.shutdown();
}
});
serviceManager.registerShutdownOnExitHook(); // gracefully shut down on
CTRL-C
serviceManager.startAllAndWait();
logger.info(Service startup took + stopwatch.elapsed());
logger.info(Ready);
}
Ideally ServiceManager has a rich API that lets you do all the natural
things you want to do with services. Stuff like starting them up, shutting
them down, listening for state changes, printing statistics like startup
time, and interrogating the dependency graph. It could even do its own
logging (in a verbose mode?) to keep the common case concise.
--
You received this message because you are subscribed to the Google Groups
google-guice-dev group.
To post to this group, send email to google-guice-dev@googlegroups.com.
To unsubscribe from this group, send email to
google-guice-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #74 on issue 62 by cow...@bbs.darktech.org: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Hey Bob, Glad to see that you're still alive :) I think that this feature needs to be split into two: 1. A built-in @PreDestroy behavior that invokes close() on all instances of Closeable. 2. Support for @PostConstruct, @PreDestroy and other annotations. Everyone seems to be on-board for #1. There seems to be some controversy surrounding #2. Couldn't we resolve them separately? -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #72 on issue 62 by kvas...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 Just in case somone interested. mycilla-guice works ok for @PostConstruct and @PreDestroy for me, but I had one problem: guice+mycilla does not work ok when guice fails to create injector (in case some of services failed to start). Theese patches add: * do not allow to recreate singleton objects after error * perform destroy upon injector create error Attachments: guice-singleton-recreation.patch 2.2 KB mycilla-destroy-on-error.patch 3.8 KB -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #70 on issue 62 by dha...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 You can try Sitebricks's AwareModule as a lightweight lifecycle support for Guice. https://github.com/dhanji/sitebricks/blob/master/sitebricks-web/src/main/java/info/sitebricks/persist/PersistAware.java And the module looks like: https://github.com/dhanji/sitebricks/blob/master/sitebricks-web/src/main/java/info/sitebricks/persist/StoreModule.java -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #71 on issue 62 by kvas...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 And what about injector creation errors ? Some services may be already started in case of partially created injector and we defenitely need to stop them... -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-dev@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #64 on issue 62 by limpbizkit: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 @61: the goal of Guava's service interface is to do the concurrency for you. Clients who want to start services just call start/startAndWait(). Those methods are idempotent and allow you to shutdown a service asynchronously. People defining their own service implement AbstractExecutionThreadService, where they implement startup, run loop, and shutdown methods. http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/util/concurrent/AbstractExecutionThreadService.html -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-...@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #53 on issue 62 by christia...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 There's no need for the manager to call everything before anything is returned - we have a dependency graph, we can just call startup along the dependency chains. Anyway, Jesse Wilson and I had a similar conversation about five weeks ago (I think) and came to a similar conclusion about an interface. I was working up a proposal, but hadn't seen this bug. I DO think it's important that we not go with the start everything approach. Too much up-front hit, I think. Wiring should happen up-front, but one point of separating out wiring from config from startup is to keep the costs of these pieces of work separate (and maintainable). The other thing that needs to happen with any lifecycle system is a strong set of recommendations on where to do what kinds of work, so people have a clue. So much work is done in providers and constructors to-date, that having good instructions could ease migration to using the lifecycle in a maintainable and sane way. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-...@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #54 on issue 62 by christia...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 And yes, I'm volunteering. :) -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-...@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #55 on issue 62 by sberlin: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 We have a dependency graph for use/construction dependencies, but not for service requirements. It's fairly often that a service (Foo) needs other services (Bar, Baz) setup (either initialized or up running) before Foo can start, despite Foo not having a Guice-visible dependency on Bar/Baz. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-...@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #57 on issue 62 by dhanji: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 We discussed this at length, and were pretty convinced that best solution is for the user to manage the dependency order with the help of a CompositeService: Service.start() // called from main() CompositeService - calls Service1.start(); Service2.start(); etc. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-...@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #58 on issue 62 by sberlin: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 @dhanji -- So long as multiple .start() calls are ignored (the service isn't started twice), and the returned Future from latter calls still works for blocking.. that seems like a good plan. I'm a little scared about having an insanely large CompositeService -- kind of like an additional Module, except for service ordering instead of object wiring. @cwg -- It's often the case that a service has no need for a real wiring dependency on something else, but it still has a service dependency on it. It would be ashame, I think, to force an object dependency on it. This has been what's nice about Guice not including lifecycle as part of a base feature -- it separates lifecycle dependencies from object dependencies. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-...@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #60 on issue 62 by christia...@gmail.com: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 sigh I was afraid this was where Guice was going to go... I wholeheartedly disagree that composite-service wtih a separate listing of dependency is the way to go. For me, a collaborator dependency graph IS the order in which B needs A, and usage-order/start-order implies construction order (as in, if B needs A to be started before it needs to be started, it surely needs A to exist before it needs to exist. Even if it doesnt' know about A, because it's transitive. So I don't see it as an artificial dependency, but an absolutely natural one, implicit in the creation graph. But even if it was artificial, with a CompositeService (which isn't really a feature of guice, as I can do this with a Multibinder today), you're basically specifying a separate, duplicate wiring which (as I said) overloads (to an extent) the creation graph. That's maintaining metadata twice, which (again, to me) is really hard to maintain. I've long considered the lack of lifecycle a bug, not a feature, and a radically bad design choice, and what I've seen in terms of people adding work to constructors/providers as a workaround the missing feature (to me) justifies this view. I'll dig back through the bug and conversations and see if I can't convince myself otherwise, but Im afraid I wasn't convinced when I first read the arguments about we're an injector not a container and I suspect I won't find much new to convince me. And I'm sorry if I'm a little snippy in this bug thread, but I had built up hopes and I'm actually really disappointed in this decision, because I really really really want to like Guice, and it's clean in so many other ways. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-...@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
Re: Issue 62 in google-guice: Lifecycle support
Comment #62 on issue 62 by dhanji: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62 @60 What do you mean by a implies b ordering, in practical terms? Are you saying you want any class in the injector that impl's Startable to have start() called on it? Trying to understand... certainly don't want you to stop liking Guice! @hani We can support the javax.* annotations as an optional module using Service. The Service scheme is mainly meant to nail down the conceptual programming model. There's no problem with supporting different annotations. -- You received this message because you are subscribed to the Google Groups google-guice-dev group. To post to this group, send email to google-guice-...@googlegroups.com. To unsubscribe from this group, send email to google-guice-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
