On 03/10/2014 09:27 PM, Nate Bauernfeind wrote:
No actually you don't get already bound exceptions. Guice actually
treats the injection as a setter based injection (it doesn't care how
you name methods; but I tend to use the word register since it
seems to
suggest
I agree. If these objects weren't meant to exist throughout the life of my
application then binding them as singletons is not a good idea.
Additionally, you wouldn't want the listener subscription to last forever
either. I instead move subscribe and unsubscribe into start and stop
methods. In
Just finished reading through the stack overflow link; thanks for sharing
it. It reminded me of the following:
I've heard/read/adopted the policy that guice modules should sincerely
avoid any conditional logic. If you do find yourself with some conditional
logic try and split your module up by
This sounds like a good idea but wont to get a Already bound exception ?
Den mandag den 10. marts 2014 20.26.26 UTC+1 skrev Nate Bauernfeind:
Just finished reading through the stack overflow link; thanks for sharing
it. It reminded me of the following:
I've heard/read/adopted the policy
That makes a lot of sense, thanks. I'm not sure it will solve all
scenarios..but lets see.
Den mandag den 10. marts 2014 21.27.38 UTC+1 skrev Nate Bauernfeind:
No actually you don't get already bound exceptions. Guice actually treats
the injection as a setter based injection (it doesn't
Still, since not all classes are injectable (third party) you might need to
access them and populate them manually..
Den mandag den 10. marts 2014 21.27.38 UTC+1 skrev Nate Bauernfeind:
No actually you don't get already bound exceptions. Guice actually treats
the injection as a setter based
in case anyone has the same problem..this is my solution so far (a real
world example)
class WorldPhysXModule extends Module {
val world: WorldPhysX = new WorldPhysX
@Provides
@Singleton
@Named(dimensionScale) def dimensionScale(settings: IProperties): Float
=
It's nice to see another scala fan. You may consider checking out
scala-guice ... some helper stuff that makes guice more scala friendly.
https://github.com/codingwell/scala-guice
It seems odd that you're extending Module directly; I think I've only ever
needed to use AbstractModule or
FYI, injecting a MembersInjectorWorld into the '@Provides provideWorld'
and calliing injectMembers(world) will remove the need to do the
requestInjection in configure.
sam
On Mon, Mar 10, 2014 at 6:11 PM, Mikkel Petersen mlp2...@gmail.com wrote:
in case anyone has the same problem..this is
Im not sure what you mean could you post a small example ?
Den mandag den 10. marts 2014 23.28.52 UTC+1 skrev Sam Berlin:
FYI, injecting a MembersInjectorWorld into the '@Provides provideWorld'
and calliing injectMembers(world) will remove the need to do the
requestInjection in configure.
How else would I create a module unless I subclassed it
? binder.requestInjection(binder) is an error, dont know why its there (it
didnt do anything, good or bad though:)
You're right, why would I inject World if theres nothing to inject ? well,
my argument lists gets smaller and smaller:)
@Provides provideFoo(MembersInjectorFoo fooInjector) {
Foo foo = new Foo();
fooInjector.injectMembers(foo);
return foo;
}
Also answered
herehttp://stackoverflow.com/questions/4844101/how-to-inject-things-on-objects-that-were-created-using-reflection
.
sam
On Mon, Mar 10, 2014 at
The latest example, with garbage removed
class WorldPhysXModule extends AbstractModule {
val world: WorldPhysX = new WorldPhysX
@Provides
@Singleton
@Named(dimensionScale) def dimensionScale(settings: IProperties): Float
= settings.getFloat(dimensionScale)
@Provides
@Singleton
def
Oh yes im normally also extending AbstractModule. I was trying something
else out..so just ignore that..
Den mandag den 10. marts 2014 23.21.41 UTC+1 skrev Nate Bauernfeind:
It's nice to see another scala fan. You may consider checking out
scala-guice ... some helper stuff that makes guice
Thanks sam..thats usefull
On Mon, Mar 10, 2014 at 11:41 PM, Sam Berlin sber...@gmail.com wrote:
@Provides provideFoo(MembersInjectorFoo fooInjector) {
Foo foo = new Foo();
fooInjector.injectMembers(foo);
return foo;
}
Also answered
On 03/10/2014 09:27 PM, Nate Bauernfeind wrote:
No actually you don't get already bound exceptions. Guice actually
treats the injection as a setter based injection (it doesn't care how
you name methods; but I tend to use the word register since it seems to
suggest not saving the object).
Interesting! Have you found a significant performance overhead? I tend to
hide bindings like these in a private module, but I doubt that would make
their cost any cheaper. Can you explain what the cons are from this
approach? I do things like this all the time now.
Thanks,
Nate
On Mar 10, 2014
Why do this list even exists then ? Of course I was looking for a response
and a solution, I was just a little surprised that people would spent more
energy trying to look for errors in my code instead of addressing the issue.
A simple No, what you're trying to do is not possible, try
You bring up a good point... Why does this list exist? It existed prior to
the fantastic take off of the stack exchange platform and so we should
consider the modern purpose of this list. Thank you for pointing out this
mis-match of purposes.
I will start a separate thread to discuss the
Are you suggestion I should google around and ask ? thanks, would have
never thought about that..
Den lørdag den 8. marts 2014 03.45.59 UTC+1 skrev Sam Berlin:
I hate to break it to you, but it increasingly looks like you're making
this much harder for yourself, using the framework in a way
Btw, Multibindings doesnt solve this..but I'm glad that you told me I do
things wrong, without telling me why, and without providing an alternative
solution. Did you even look at the sample ?
Den lørdag den 8. marts 2014 15.51.21 UTC+1 skrev Mikkel Petersen:
Are you suggestion I should google
I suggested going specifically to StackOverflow, which is a website devoted
to programming questions/answers.
Additionally, I suggested a solution of Multibindings, which AFAICT is
specifically for the problem you outlined.
If you have further problems, I'm not sure I can help much more, though
Well multiibindings solves, in a way, the listener problem. Because it
works on sets. But it doesnt solve if I wanted to access other objects from
other modules.
If you could care to explain to me why this is wrong without saying its
just wrong I'm all ears.
You might as well say that using a
It does depend on how you're doing your listener pattern, but Guava's
EventBus might be a nice alternative, like I explained in an earlier email.
I think Sam was just pointing out that it seems like you're using Guice in
an unintended way. Which can decrease the satisfaction of your particular
Yes, but project was started before eventbus existed. Stil, I would like to
make the conversion.
I too thought about the inject modules first solution. I think its a bit
silly though, and smells like a workaround from something that should be a
lot easier to do.
Den lørdag den 8. marts 2014
Also, the modules that configures the module might grow in complexity..then
what ? make another module that configures the module that configures the
module ?
Den lørdag den 8. marts 2014 22.19.35 UTC+1 skrev Mikkel Petersen:
Yes, but project was started before eventbus existed. Stil, I
Theres a thread about it in Stackoverflow.
http://stackoverflow.com/questions/5504555/guice-is-it-possible-to-inject-modules
Den lørdag den 8. marts 2014 17.11.57 UTC+1 skrev Nate Bauernfeind:
It does depend on how you're doing your listener pattern, but Guava's
EventBus might be a nice
Too bad this has to be unresolved. Google ignores it, for some weird
reason.
On Sat, Mar 8, 2014 at 10:34 PM, Mikkel Petersen mlp2...@gmail.com wrote:
Theres a thread about it in Stackoverflow.
http://stackoverflow.com/questions/5504555/guice-is-it-possible-to-inject-modules
Den lørdag
I'm going to point out that Google doesn't ignore this thread -
Google as a corporation does not offer any guarantees or warrantees or
service-level-agreements with respect to Guice, which is clear in the
Apache license attached to every file.
You asked a question on a developer community
Hello all
I have a slight problem with guice injection when using a method annotated
with @Provides
example :
@Provides
public Service someService() {
return new SomeService()
}
I would like to get the current context injected in SomeService..I don't
understand why Guice doesn't do that
What about your use case prevents you from using a normal .to binding?
bind(SomeService.class).to(SomeService.class)
Nate
On Fri, Mar 7, 2014 at 4:13 PM, Mikkel Petersen mlp2...@gmail.com wrote:
Hello all
I have a slight problem with guice injection when using a method annotated
with
Because I want to receive other bindings:
public Service someService(@Inject Settings settings) {
SomeService s = new SomeService(settings.getHost())
inj.injectMembers(s)
return s
}
Den fredag den 7. marts 2014 23.32.42 UTC+1 skrev Nate Bauernfeind:
What about your use case prevents
Your service can receive other bindings by having them injected into its
constructor. If the class is defined as:
class SomeService {
@Inject SomeService(Settings settings) { ... }
}
.. then when others inject the service, Guice will create it with the
correct dependencies for you.
Is
It's a bit more work, but you could consider using assisted injection for
this kind of use-case. My typical pattern looks like this:
public class Example {
@Inject
public Example(@Assisted(host) String host
HttpClient httpClient,
...) {
...
Oops, I apologize, I left off this other method on the module (these
methods are in generic abstract modules that I inherit from, one that
extends from AbstractModule and the other from PrivateModule):
protected T, F void bindFactory(ClassT source, Class? extends T
klass, ClassF factoryKlass) {
Thanks for your response.
It's seems overly complicated and I must admit, I don't understand it
fully..though it properly works..I fail to see the usage of @Provides
methods if the object provided doesn't have the object graph injected.
Den fredag den 7. marts 2014 23.54.17 UTC+1 skrev Nate
@Provides are typically when you need to inject an instance of some library
out of your control that doesn't have any guice bindings. I try to avoid
using providers for any other use case. In your specific example, I would
do what Sam suggested and just simply inject the Settings object.
I use
Thank you all for your responses !
Problem is, my application has grown to the point that even the modules
themselves have becoming an application.
So there are many objects created in different modules, needed by others...
What I really need is to be able to inject dependencies into module.
I can't say that I've ever dealt with an experience of having 100+ unique
modules (now if you want to talk about 100+ child injectors created from
different instances of the same module (i.e. as a template)... now that
I've done). I think my largest experience has sliced things up into maybe
15
I have already optimized each and every module..I have spent years doing
that, really. But they still run into the exact same problem that Guice was
supposed to solve: how do we get object A to object B.
With hundreds of modules, that problem will occur over and over..For
example, I have a list
I don't understand why your modules need things injected. The point of
modules is to set up rules saying this is bound to that and when someone
wants this, give them that. It does not require knowing the
interrelationships of each object. I highly suspect there's something
fundamentally wrong
41 matches
Mail list logo
