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 with your setup, but it's hard to say for certain
without knowing what you're doing.
sam
On Fri, Mar 7, 2014 at 7:18 PM, Mikkel Petersen <mlp2...@gmail.com> wrote:
> 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 of Listeners in Module A. Module A binds them, plus
> add some listener code to the list. Module XYZ23B now wants to add a
> listener to this list as well. How ? Only solution right now is to have a
> class that references this list public and statically. Now, you could say,
> my logic is wrong. All logic concerned this listener list should be in one
> module..but perhaps the two do not have much in common logic wise than this
> object.
>
> Den lørdag den 8. marts 2014 01.08.14 UTC+1 skrev Nate Bauernfeind:
>>
>> 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 modules; which is still quite a handful to manage.
>>
>> The biggest thing that I did that helped managed dependency relationships
>> across modules was to prefer PrivateModules over completely public
>> AbstractModules. It made me really think about what each module was being
>> used for and what it exposed for use with the rest of the application. For
>> example, I don't mind creating a different ExecutorService that might be
>> used in an entire sub-graph that is not shared across all of my modules. In
>> fact, limiting how portions of your application can interact, or interfere,
>> with each other can dramatically improve your experience when debugging or
>> fine-tuning certain things.
>>
>> Perhaps, migrating and merging some of your modules to each have a
>> specific purpose might bring things back to being manageable and meaningful
>> for you.
>>
>> Additionally, I've had some experience here and there using Guava's
>> EventBus to further decouple sub-systems by instead communicating with
>> messages. For example instead of injecting the TwitterService and have
>> every listener register itself as a listener, I instead can use the
>> EventBus to subscribe to all messages of a type "TwitterEvent" and then the
>> messages get to the right places behind the scenes on my behalf (you only
>> need to add an @Subscribe assuming you let guice register your objects).
>> This works well for data that flows as opposed to data that you need to
>> pass back an answer (though I've tried this too by passing a settable
>> Future as a means of a lightweight callback -- but I wasn't extremely
>> satisfied, nor unsatisfied, with the result). The applications that I have
>> that use an event bus can typically remove a guice module from the list
>> that gets passed into the injector and everything will still start up and
>> run appropriately -- just no one will get any TwitterEvents if that module
>> was removed.
>>
>>
>> On Fri, Mar 7, 2014 at 5:16 PM, Mikkel Petersen <mlp...@gmail.com> wrote:
>>
>>> 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.
>>>
>>> The ideal solution would be
>>> TestModule extends Module {
>>> Inject SomeObjectCreatedInAFarWayModule someObject;
>>> }
>>>
>>> But that is not possible, so because of that I took a look at providers,
>>> which allow dependencies to be injected into modules.
>>> My application has at least 100 modules by now, and growing.
>>> So far I have used static public objects, but as everyone knows, that is
>>> bad practice.
>>>
>>>
>>>
>>>
>>> Den lørdag den 8. marts 2014 00.07.22 UTC+1 skrev Nate Bauernfeind:
>>>>
>>>> @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 dropwizard a lot and typically finding myself creating
>>>> hierarchical configuration objects, and passing the sub-configuration
>>>> object to a specific module. For example,
>>>>
>>>> class ApplicationConfiguration {
>>>> public DatabaseConfiguration data;
>>>> public TwitterConfiguration twitter;
>>>> ...
>>>> }
>>>>
>>>> And then they map one-to-one to a top-level PrivateModule which accepts
>>>> the sub-configuration object as part of its constructor. Then I can easily
>>>> either inject the configuration class privately for that sub-portion of my
>>>> application, or do whatever I need to with it (like configure an http
>>>> client in a @Provides method).
>>>>
>>>> Happy Guicing!
>>>>
>>>>
>>>> On Fri, Mar 7, 2014 at 5:00 PM, Mikkel Petersen <mlp...@gmail.com>wrote:
>>>>
>>>>> 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 Bauernfeind:
>>>>>>
>>>>>> 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,
>>>>>> ...) {
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>> /** This class is a Guice Assisted-Inject Factory. */
>>>>>> public static interface Factory {
>>>>>> Example newExample(@Assisted("host") String host);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> public class ExampleModule {
>>>>>> void configure() {
>>>>>> bindFactory(Example.class, Example.Factory.class);
>>>>>> }
>>>>>>
>>>>>> protected <T, F> void bindFactory(Class<T> klass, Class<F>
>>>>>> factoryKlass) {
>>>>>> bindFactory(klass, klass, factoryKlass);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> And then you can still use a provider method (if you prefer!) and
>>>>>> then you inject the factory and the settings.
>>>>>>
>>>>>> @Provides
>>>>>> public Example someExample(Example.Factory factory, Settings
>>>>>> settings) {
>>>>>> return factory.newExample(settings.getHost());
>>>>>> }
>>>>>>
>>>>>> Hope that helps! I use this pattern a lot, but not often mixed with a
>>>>>> Provider -- usually I have a class that manages the multiple instances
>>>>>> key'ed by some name (like client or user).
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 7, 2014 at 4:44 PM, Mikkel Petersen <mlp...@gmail.com>wrote:
>>>>>>
>>>>>>> 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 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
>>>>>>>> <mlp...@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> 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 automatically, any
>>>>>>>>> particular
>>>>>>>>> reason for that ?
>>>>>>>>>
>>>>>>>>> I know I could do something like this (it works):
>>>>>>>>>
>>>>>>>>> @Provides
>>>>>>>>> public Service someService(@Inject Injector inj) {
>>>>>>>>> SomeService s = new SomeService()
>>>>>>>>> inj.injectMembers(s)
>>>>>>>>> return s
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> But there must be a simpler way.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Ps, another question, how to add syntax highlighting ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>> Groups "google-guice" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>> send an email to google-guice...@googlegroups.com.
>>>>>>>>> To post to this group, send email to google...@googlegroups.com.
>>>>>>>>>
>>>>>>>>> Visit this group at http://groups.google.com/group/google-guice.
>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "google-guice" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to google-guice...@googlegroups.com.
>>>>>>> To post to this group, send email to google...@googlegroups.com.
>>>>>>> Visit this group at http://groups.google.com/group/google-guice.
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>
>>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "google-guice" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to google-guice...@googlegroups.com.
>>>>> To post to this group, send email to google...@googlegroups.com.
>>>>> Visit this group at http://groups.google.com/group/google-guice.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "google-guice" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-guice...@googlegroups.com.
>>> To post to this group, send email to google...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/google-guice.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "google-guice" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-guice+unsubscr...@googlegroups.com.
> To post to this group, send email to google-guice@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-guice.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-guice+unsubscr...@googlegroups.com.
To post to this group, send email to google-guice@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/d/optout.
