2009/2/4 Witold Szczerba <[email protected]> > > Hi there, > I hope it is not too late, the Guice 2.0 is to be released soon... > I am developing rich client (Swing) backed by EJB3 server providing > many session beans through remote interfaces. This is very easy to > lookup session bean: you just have to know its name and that's it. > More than that: every EJB server has its own naming conventions, so I > do not event have to know that name: it can be guessed based on the > class name of the interface. However, for Guice to be able to inject > some object via interface - it does have to be implicitly registered > in module. So every single remote interface has to be mentioned in > module. > > To summarize: > in module I have to: > > someServiceBean = lookup(SomeServiceRemote.class); > bind(SomeServiceRemote).toInstance(someServiceBean); > > the above has to be repeated for EVERY session bean in order to be able to > do: > > @Inject > SomeServiceRemote someServiceBean; > > I have simple workaround for that issue: what if I drop that bindings > in module (so there is no need to explicitly list every possible > session bean) and would inject my service like this: > > @Inject @EJB > SomeServiceRemote someServiceBean; > > Now all I would have to do for Guice to be able to figure out what to > inject, would be to bind my custom EJB Provider to the @EJB annotation > instead of the service's interface class. But in order to lookup the > bean in my provider, I would have to get access to the context, so I > could get the SomeServiceRemote.class as some parameter. If that could > be done, I would be able to inject any session bean: > > @Inject @EJB > SomeServiceRemote someServiceBean; > @Inject @EJB > AnotherServiceRemote anotherServiceBean; > @Inject @EJB > YetOneMoreServiceRemote yetOneMoreServiceBean; > > and many many more, all handled by just one, mega powerful provider :) > The so called mega powerful provider would have an option to request > for some kind of context, where I could figure out everything about > that particular injection which caused the request. In the case above, > that could be: > 1) the collection of every annotation with parameters (if were provided) > 2) the requested interface/class to be returned > 3) optionally something more...? > What do you think about it? >
this has been raised before and there are a couple of open issues: http://code.google.com/p/google-guice/issues/detail?id=27 http://code.google.com/p/google-guice/issues/detail?id=49 however, with great power comes great responsibility ;) the main reason (afaik) there hasn't been much progress on either of these issues is that it can quickly lead to systems where it's hard to tell how things will behave at runtime, or indeed if everything has been configured correctly I believe the Guice team understand the need, but prefer to take the cautious route (it's easier to add features than remove them later on) you might also want to look into writing a custom module that can take a list of remote interfaces and go through them adding bindings like: for (Class<?> remote : someList) { // list was passed into module constructor bind(remote).annotatedWith(EJB.class).toProvider(new BeanProvider(remote)); } Each BeanProvider then knows what interface to use in the lookup. You could even go further and configure your module by scanning the application classes for injection points or reading in some file. IMHO most of the need for the injection context could be avoided by writing this sort of 'smart' module... Regards, > Witold Szczerba > > P.S. > In previous application, for accessing session beans, I had (ble, > ugly) static method: > T Services.get(Class<T> remoteInterface) {...} > Using Guice 1.0 it is not enough to get rid of that method and use > injection. The module has to be aware of every session bean. If my > proposition would be included into Guice 2.0 it would be much easier > to replace such a custom static methods with Guice's DI. > > > > -- Cheers, Stuart --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
