On Mar 17, 2009, at 6:37 PM, [email protected] wrote:
> > On Mar 17, 5:58 am, James Strachan <[email protected]> wrote: >> In attempting to implement it with Guice the main complication seems >> to be using the extra development/production deployment annotation >> matching stuff - which is quite handy - and that producer methods >> don't have to be on a Module implementation (which is also useful). > > The last time I looked, JSR 299 doesn't have the concept of a Module. > Instead, the configuration uses classpath scanning, annotations and > annotation-like XML. I anticipate that this may make testing > cumbersome, but I haven't tried it. JCatapult uses classpath scanning for Guice modules with support for inheritance and it works pretty well. I haven't run into major issues with it in general and it does simplify what we consider our general usage cases. In general testing remains the same as any other situation. Some tests inject the full service, some tests mock stuff out, and some mock bits and pieces via additional modules or inheritance. Both classpath scanning and testing can obviously break down eventually, but I haven't hit that case yet. Another general rule we put into JCatapult is always allow folks to turn it off or tweak it. For this reason you can just flip a switch and classpath scanning is turned off and it reverts to a configured list of modules. We also added an excludes list when scanning is turned on and a few other things. I tend to like technologies that make things really simple up front but also allow me to do whatever I want without major hassle. -bp --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
