Comment #39 on issue 62 by heinz.in.ulm: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62
Hi, i write this because of some frustation reading the block here. For me it seems that some are thinking of guice as a tool for osgi and j2ee ONLY. if guice should be just that - ok - but then guice should be renamed to just another tool to make the j2ee world bigger. Guice is advertized as "next-generation dependency injection container for Java 5 and later". Back to the issue - guice outside of a managed container has no livecycle management at all if field or method injections are used. Except for "constructor only injections" there is no single point of "being initialized". But field and method injection are part of guice - aren't they? Isn't that missing livecycle a serious issue by itself? I think that's what Sun has forseen with it's javax.annotation package in java6 - smart,because this is an architecture issue not just a usage case. Someone asked here for usage cases - beside I think that's the wrong question for a fundamental package like guice - nevertheless here is one for a Swing based application: I wanted to use guice in a swing based environment to bootstrap a Swing application. Having hundreds of JPanel's needing access to hierachical application wide services. In a single panel there may be 2 to 50 other JComponent's and other classes constructed. So to use juice I found three choices: 1.) use guice and constructor only injectors for the panels- then I endup with constructors with up to 50 parameters and initialize the panel inside of this huge constructor - very very ugly 2.) pass (or inject) a Injector instance into all panels and use injector.getInstance(...) - then I don't need guice - any singleton pattern could do that same thing better. 3.) don't use guice I think we end up to go with the option 3.) Note: the application wide services in our case are hierachical and would fit very well into guice Scope and Stage concept - many of these services are not just singletons. Guice would have helped a lot if there would be a point where the panels could be "initialized" after being fully constructed (and injected). In this environment there is no way around an init() or createComponent() or postConstructed() pattern. Or you end up with "constructor-only" classes. Just to strengthen my point for those knowing the Eclipse architecture: Eclipse implementation solved this by using inheritance - ending up with a almost endless - in my opinion - very ugly class hierachy of 10th of levels of inheritance. Any simple eclipse panel (pane) knows by inheritance any service providers of eclipse!!! A Service oriented architecture for an ui would have been much cleaner. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en -~----------~----~----~----~------~----~------~--~---
