This code is not thread-safe. =( This is exactly why encourage people to use Guice singletons and discourage the traditional singleton (anti-)pattern. Dhanji.
On Wed, Jan 14, 2009 at 11:32 PM, Eric Anderson <[email protected]>wrote: > Rick, > > The code I posted was... overly simplistic. Yes, creating the injector > multiple times could be very costly depending on what is getting > initialized. A more complete solution would use a lazy-loaded injector > singleton: > > import com.google.inject.*; > import java.util.*; > > public class ServiceCreator { > > Injector injector; > private static ServiceCreator INSTANCE = new ServiceCreator(); > > public static <T> T createService(Class<T> clz) { > return INSTANCE.getInjector().getInstance(clz); > } > > private Injector getInjector() { > if (injector == null) { > injector = Guice.createInjector(getModules()); > } > return injector; > } > > private Collection<Module> getModules() { > HashSet<Module> modules = new HashSet<Module>(); > > //Add modules here > > return modules; > } > } > > This keeps the injector as a field on the ServiceCreator instance. It > would be easy enough to tweak the code above such that you could have > clients using the ServiceCreator instance rather than a static method. If > you're trying to do thorough unit testing, I might be tempted to expose the > instance of ServiceCreator rather than static methods so that ServiceCreator > could be put behind an interface. > > The main thought was to hide the working of Guice behind a thin facade. I > personally haven't ever needed to do this since our apps use Guice > throughout. But, we have had to wrap external dependencies, and this is how > we've done that (although we do tend to put them behind an interface). > > Eric > > > On Tue, Jan 13, 2009 at 3:37 PM, Rick <[email protected]> wrote: > >> >> On Tue, Jan 13, 2009 at 4:03 PM, Eric Anderson >> <[email protected]> wrote: >> > You could always expose a thin static wrapper over the injector so that >> > users don't have to know about the Guice modules or the injector for >> that >> > matter. What I might do is this: >> > >> > >> > class ServiceCreator { >> > public static <T> T getBar(Class<T> clz) { >> > return Guice.createInjector(modules).getInstance(clz); >> > } >> > } >> > >> > The clients can decide how they want to consume something like this. >> I'm >> > assuming that you're talking about existing applications that are NOT >> > currently using IoC. >> >> >> Thanks Eric for your reply... in regard to existing applications NOT >> currently using IoC... I guess that's partially true. Since the jar's >> main use will be inside of a tibco ESB in a NEW application, I could >> force them to use Guice.... but I really don't figuring out with them >> at what part should I hook in to get Guice bootstrapped. I was hoping >> to keep the Guice I'm using relatively transparent to them.. so for >> example they would just use the classes provided as singletons or >> static methods to do the basic dao operations (ie >> updateEmployee(Employee e). >> >> In regard to the code posted above I have to admit I'm a bit confused >> by how it would be used. I suppose the real implementation would be >> called getService(Class<T> clz) ? >> >> and the end user would have to call something like... >> >> EmployeeService service = ServiceCreator.getService(EmployeeService.class) >> ? >> >> If so I'm confused though, wouldn't the end users be calling >> Guice.createInjector(modules) a bunch of times? >> >> There would also be the need to return other Service classes to the >> end user as well. Or does it not hurt to call createInjector multiple >> times? >> >> Thanks again for the help. >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" 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?hl=en -~----------~----~----~----~------~----~------~--~---
