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 <[email protected]> wrote: > 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 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 experience. >> >> Which, of course is a shame, because Guice has been an amazing experience >> for me, and I won't do any project without it. >> >> It should technically be possible to have a two stage dependency >> injection setup. I've personally toyed with the idea as a way to decouple >> configuration from the application (before I started using dropwizard I >> used multiple json files that would auto inject @Named strings). It should >> work in your case as well if you name your collections and inject them into >> your modules. >> >> So the idea is that the first injector is created to instantiate all >> modules, so you would need very few super modules that binds each of your >> original modules. You will likely want to use multibinder to register each >> module so that you can pull them directly off of this initial injector to >> construct the second phase injector. >> >> It should work and may help with the problem you've found yourself in. >> >> If you feel like you can share a handful of module source files with me, >> out of thread, I'd be happy to see if there are even better and more >> concrete suggestions I can give you. >> >> Nate >> On Mar 8, 2014 9:02 AM, "Mikkel Petersen" <[email protected]> wrote: >> >>> >>> 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 injection framework is wrong because >>> injection is a sign that the logic in your application is wrong. >>> I'm not convinced at all that my clam is not legitimate but we can >>> disagree on that, no problem. I'll simply note that at this point, Guice >>> can't handle this problem. >>> Den lørdag den 8. marts 2014 15.56.16 UTC+1 skrev Sam Berlin: >>>> >>>> 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 >>>> others on this list may be able to. >>>> >>>> sam >>>> >>>> >>>> On Sat, Mar 8, 2014 at 9:54 AM, Mikkel Petersen <[email protected]>wrote: >>>> >>>>> >>>>> 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 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 it's >>>>>>> not >>>>>>> intended. >>>>>>> >>>>>>> For this particular problem (adding things to a shared pool), >>>>>>> there's an extension called Multibinder: http://code.google.com/p/ >>>>>>> google-guice/wiki/Multibindings . >>>>>>> >>>>>>> For other issues, you may want to consider asking for specific >>>>>>> guidance and help in StackOverflow (or searching for existing >>>>>>> questions/answers). I suspect you'll find that things will become a lot >>>>>>> simpler. >>>>>>> >>>>>>> sam >>>>>>> On Mar 7, 2014 7:33 PM, "Mikkel Petersen" <[email protected]> wrote: >>>>>>> >>>>>>>> It's hard for me to describe the entire problem..I was really just >>>>>>>> looking for a solution to this, now it has turned into something else. >>>>>>>> But >>>>>>>> fine, I'll try to explain my point further. >>>>>>>> >>>>>>>> Lets say its not fully possible to populate an object just from >>>>>>>> Module, that other modules should have access to this object as well in >>>>>>>> order for it to be fully ready for use. >>>>>>>> >>>>>>>> For example, we have an object NameList >>>>>>>> >>>>>>>> Module A { >>>>>>>> configure() { >>>>>>>> nameList = new NameList() >>>>>>>> bind(NameList.class).toInstance(nameList) >>>>>>>> name = new Name("peter") >>>>>>>> requestInjection(name) >>>>>>>> nameList.add(name) >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> Module B { >>>>>>>> Name name = new Name("James") >>>>>>>> requestInjection(name) >>>>>>>> nameList.addName(name) >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> Module B binds a new name, injects it, and adds it to the NameLIst. >>>>>>>> But the namelist was created and bound in module A !! How will it get a >>>>>>>> reference to NameList ? >>>>>>>> We could do something like this >>>>>>>> >>>>>>>> GuiceStatics { >>>>>>>> public static NameList nameList >>>>>>>> } >>>>>>>> And access it from here. Or make a singleton factory or whatever. >>>>>>>> But why ? this is what Guice helps us to avoid ! >>>>>>>> >>>>>>>> Point is, the entire module section of any application can grow >>>>>>>> into something huge itself. And because of that, it needs dependency >>>>>>>> injection itself. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Den lørdag den 8. marts 2014 01.22.37 UTC+1 skrev Sam Berlin: >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> <[email protected]>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 < >>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>>> [email protected]> 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 [email protected] >>>>>>>>>>>>>>>>>> om. >>>>>>>>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>>>>>>>> [email protected]. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Visit this group at http://groups.google.com/group >>>>>>>>>>>>>>>>>> /google-guice. >>>>>>>>>>>>>>>>>> For more options, visit https://groups.google.com/d/op >>>>>>>>>>>>>>>>>> tout. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>>>>>> [email protected]. >>>>>>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>>>> [email protected]. >>>>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>> To post to this group, send email to [email protected] >>>>>>>>>>>> . >>>>>>>>>>>> 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 [email protected]. >>>>>>>>>> To post to this group, send email to [email protected]. >>>>>>>>>> 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 [email protected]. >>>>>>>> To post to this group, send email to [email protected]. >>>>>>>> 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 [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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 a topic in the > Google Groups "google-guice" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/google-guice/HMj5hmPjmR4/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/google-guice. > For more options, visit https://groups.google.com/d/optout. > -- Med venlig hilsen/Best regards Mikkel Petersen Jagtvej 82 4th 2200 København N Telefon 35 37 63 10 Mobil 91 97 03 64 -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-guice. For more options, visit https://groups.google.com/d/optout.
