Thanks for the suggestions. I kinda decided to go for the unsupported approach. It only took me a few lines of code to get access to the context when inside a Provider it just means I need to access package privates. I would have preferred to do it in a supported way, but It clashes with the Guice philosophy.
Adding extra "power" features certainly come with a risk of people abusing it, I can certainly respect that. It is just a shame that because of risk of abuse that certain features are not even remotely considered. As for my use case. Well, it is just a trimmed down version of what I really need. The interface mechanism with annotations does a lot more than what I show here. The huge advantage is that I get compile time checks that all my alerts are properly used, it supports i18n, severity, routing info, can be used both in GWT on the client and on the server in J2EE or OSGI ... etc. The design is clean and easily mockable for testing as well. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CABrJHW1T1igcRkEbN%3DsHmoapwR_%3D3HRbAZ9VmNWMSLjQkLT6bQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
