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 <mlp2...@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+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.
