Comment #61 on issue 62 by [email protected]: Lifecycle support http://code.google.com/p/google-guice/issues/detail?id=62
My problem with the Service approach is just the same as it is with every other proposed solution. The attitude is 'we'll come up with something complex to address every single case, then it's up to the community to do the simplification that 95% of apps need'.
Sure, the Service interface would do the job. Except I now have to implement an interface, and I suddenly have to know about concurrency and futures and states.
If I'm the kind of person who knows al that, chances are I'm also clever enough to do all that in my @PostConstruct method.
I accept the religious argument against any external dependencies (or rather, am resigned to it). So how about guice specific versions of the standard annotations? Hell, give them the exact same name and just put them in a guice package. That way the totally awesome google code wouldn't have to be polluted with javax filth.
Also sorry for the snippy tone, probably cos I'm angry at myself for forgetting to celebrate the 3 year anniversary of this issue!
-- 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.
