You can use non-empty constructors with guice, just annotate it with
@Inject to say that the construction parameters should be injected. In
this case, however, I suspect that you want to provide the map as a
parameter, in which case you should check out assisted injection:
http://code.google.com/p/
Forget this, just found the answer in the doc:
http://code.google.com/p/google-guice/wiki/Scopes#Scopes_and_Concurrency
Cheers,
Philippe
On Sat, May 15, 2010 at 3:07 PM, PhilBeaudoin
wrote:
> From my (admittedly limited) understanding of servlet container
> mechanics, I understand that diff
Maybe a stupid answer, but have you tried injecting a Provider<> in
one of the two classes, instead of directly injecting the class?
Philippe
On Mon, Oct 4, 2010 at 10:44 AM, Roman wrote:
> Hi
> I have a very strange problem , that no one could explain me.
> So here is the problem. I have a c
Thanks Dhanji,
Following your recommendation I have tried to use TypeListeners to do
this. Unfortunately, it looks like TypeListeners are called after the
type's injected constructor has been scanned. As a result, if a
constructor parameter is not bound my TypeListener is never fired.
This prevent
I've been looking at the Guice source for a replacement and found
nothing. From what I've seen, if you're using JSR330 you don't have
access to optional injection. :(
Philippe
On Mon, Oct 18, 2010 at 3:24 AM, Mingfai wrote:
> hi,
>
> What's the equivalent of the "optional" value of @com.google
This brings another question, however. How do you access the injector?
I've tried injecting it but Guice complains that I cannot do that.
Cheers,
Philippe
On Wed, Nov 3, 2010 at 8:58 PM, Kartik Kumar wrote:
> If you have a reference to already instantiated object, can't you use
> Injector#in
@Fred. Strange, for some reason I remember getting an error message
when trying to do that. I just tried again and it worked.
On Wed, Nov 3, 2010 at 10:13 PM, Fred Faber wrote:
> Yes, though Injector::injectMembers will of course only work if you have a
> handle on the Injector.
>
> If you have a
Just to come back on one of my questions: is injection automatically
performed on the fields and methods of instances bound with
toInstance()?
Thanks for pointing out the MembersInjector. In this case I don't
think I can use it however, for two reasons. Tell me if I'm wrong:
1) My SpyProvider is g
On Thu, Nov 4, 2010 at 12:01 PM, Sam Berlin wrote:
> On Thu, Nov 4, 2010 at 1:00 PM, Philippe Beaudoin
> wrote:
>>
>> Just to come back on one of my questions: is injection automatically
>> performed on the fields and methods of instances bound with
>> toIns
> Good catch. It technically isn't needed in my example. But, consider the
> case where it's not split between Foo -> FooImpl, or if FooImpl was scoped
> (as, say, a @Singleton annotation on FooImpl). If it had a scoping
> annotation, toConstructor basically ignores that scope. For concrete
> c
I'm actually surprised you can inject a String into a Boolean (your
second binding). Out of curiosity, is there any reason why you
wouldn't do:
binder.bind(Key.get(Boolean.class,
Names.Named("myconfig.autoclose"))).toProvider(new Provider()
{
public Boolean get() {
Thanks for the explanation Simone, just learned one more feature of Guice today!
Also, sorry for my silly reply. :)
Philippe
On Fri, Nov 5, 2010 at 12:41 PM, Simone Tripodi
wrote:
> @Philippe
> Guice uses an extensible way to convert Strings to
> primitives/primitives wrappers/Enums and user d
I ran into a similar problem before, which I solved by updating my
deployment descriptor to serve these files as static. In my case I was
using AppEngine and the process is described here:
http://code.google.com/appengine/docs/java/config/appconfig.html#Static_Files_and_Resource_Files
I would b
It looks to me you should write your own factory, containing a:
Map>
Where StoreEntityClassInfo contains both the store class and the entity class.
Your factory would then have a:
create(Class storeClass, Class
entityClass);
The last thing you need to do is register all your Adapter classes
t
Assuming you want to do something like that:
@Inject Class theClass;
And you want it injected with Class, where SomeSubClass
extends SomeClass, then you can do:
bind(new TypeLiteral>{}).toInstance(SomeSubClass.class.getClass());
Cheers,
Philippe
On Fri, Jan 21, 2011 at 10:26 AM, Sam Berli
I forgot some parenthesis:
bind(new TypeLiteral>(){}).toInstance(SomeSubClass.class.getClass());
On Fri, Jan 21, 2011 at 11:42 AM, Philippe Beaudoin
wrote:
> Assuming you want to do something like that:
>
> @Inject Class theClass;
>
> And you want it injected with Class,
Thanks Thomas for the idea. It's an excellent one and we should
definitely pursue it in gin.
However, I'd like to probe the Guice developers on this a little more
as I feel that the ability to annotate abstract types with a scope
could be useful in other contexts as well. For example I'm using Gui
A couple of things:
1) MyInterface.class could actually be MyAbstractClass.class
2) The instance returned by GWT.create is not necessarily stateless.
So, even though both objects are equal upon creation, you can
manipulate them afterward. As a result, you don't want both calls to
GWT.create to retu
I have been using factories to do this. Something like:
class PromoFactory {
@Inject
Provider springPromo;
@Inject
Provider winterPromo;
Promo getPromo(Season season) {
if( season == Season.Winter ) return winterPromo;
return springPromo;
}
}
Then inject the PromoFactory.
Now, from your problem description, I'm not entirely sure how you
specify your zip and brands. If you were planning to use
AssistedInject but want to make sure that two different calls to the
create method return the same instance when zip & brand are the same
then you will probably have to build y
On Wed, Feb 16, 2011 at 5:25 AM, Thomas Broyer wrote:
> The best of both worlds is IMO to provide both an interface and a support
> class and suggest people to preferably extend the abstract class (see for
> instance the warning in the javadoc for
> javax.lang.model.element.ElementVisitor; others
by using @ImplementedBy. But it
> unnecessarily ties the API to the implementation, which is an even worse
> transgression IMO.
> sam
>
> On Wed, Feb 16, 2011 at 9:04 AM, Philippe Beaudoin
> wrote:
>>
>> On Wed, Feb 16, 2011 at 5:25 AM, Thomas Broyer wrote:
>&
*Copying the answer I gave to the dev group, as it should have been here...*
Injecting a Provider lets you instantiate Foo multiple times by
calling providerFoo.get().
The way Foo is generated is either:
1) The "default Guice way", if you bind(Foo.class).to(FooImpl.class)
2) Your custom way if yo
We need GUG. Guice User Groups. I'll run mine from Montreal. :)
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to google-guice@googlegroups.com.
To unsubscribe from this group, send email to
google-guice+unsub
I believe it is. I've built the equivalent of multibindings manually (by
binding various implementations using unique annotations) and it works fine.
I can't see why multibindings would do anything non-GAE friendly.
--
You received this message because you are subscribed to the Google Groups
"
You can also check out jukito: http://jukito.org
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to google-guice@googlegroups.com.
To unsubscribe from this group, send email to
google-guice+unsubscr...@googlegr
I've open sourced my own take on a similar problem:
http://jukito.org
And of course there is Guiceberry doing something like that too...
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to google-guice@googleg
Really, the biggest advantage of Jukito is in the goodies it give you. Since
you're using injection, you can easily have automocking... So Jukito does
exactly that: each time an unbound interface is found it mocks it. The tests
are a lot less brittle as a result. Something else Jukito gives you
I think the standard way to do that is to use Guice's SPI to inspect
non-bound types and provide the bindings yourself. I've used a much more
complex method in http://jukito.org but I plan to reimplement all that with
the SPI.
Cheers,
Philippe
--
You received this message because you are
Can't make it to GuiceCon but I have this nice Guice extension for testing
(in the spirit of Guiceberry, but for unit tests and automocking), which
would be probably a good candidate for a quick demo, or to include in a list
somewhere if you have such a thing... I would really have loved to join
Somehow it garbled the developers name:
philippe.beaudoin
christian.goudreau
On Wednesday, March 16, 2011 10:51:45 AM UTC-7, Philippe Beaudoin wrote:
>
> Can't make it to GuiceCon but I have this nice Guice extension for testing
> (in the spirit of Guiceberry, but for
BTW, I commited the new code using SPI to jukito's trunk. Much simpler, and
I get better error reports to boot! :)
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to google-guice@googlegroups.com.
To unsubscrib
On Thursday, March 17, 2011 5:28:48 AM UTC-7, Witold Szczerba wrote:
>
> Thanks for response, guys. The only problem is that your solutions are
> pre-injector construction, but in my case I have to provide Injector
> first and then be prepared for handling dependencies which were not
> mentioned in
Never did any Android work, but I think I remember reading that Andoid does
not work with Guice AOP. Did you use the no-AOP version of Guice?
Cheers,
Philippe
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send emai
Congrats on the release! Guice is a great tool!
BTW, how was the GuiceCon?
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to google-guice@googlegroups.com.
To unsubscribe from this group, send email to
google
35 matches
Mail list logo
