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?
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.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
