Comment #31 on issue 258 by james.strachan: [Patch] custom annotation based  
injection points
http://code.google.com/p/google-guice/issues/detail?id=258

To avoid lots of philosophical discussions (what is a standard etc) let me  
try to be
100% clear exactly what my use case is. I get the impression there's lots  
of folks
talking past each other not really hearing each other - so here's my last  
attempt at
being crystal clear.

I work on lots of application code which is used by lots of different teams  
in
different companies. This code is usually used by some IoC framework  
decided by the
user of the code (not the author of the code). Today the most common IoC  
framework I
see in use is Spring (its used in > 90% of teams I work with). Guice may or  
may not
be the best IoC container (its always gonna be subjective) - however I am  
not in the
position to dictate to all the users of my code what IoC container to use -  
nor can I
force them to refactor their code to switch IoC containers. If you're in the
googleplex this is never an issue - you can just refactor all the code to  
use
whatever you need. Outside of the googleplex the world is not so simple and  
sometimes
ideal technical solutions have to take a back seat to pragmatic decisions.

So my show stopper issue with ever adopting & recommending Guice is to be  
able to use
IoC framework agnostic annotations for lifecycle & injection (JSR 250/EJB3  
for
starters, @Resource, @PostConstruct, @PreDestroy - you could throw
Spring/WebBeans/JAX-RS/JAXWs in there too really but JSR250/EJB3 is the tip  
of this
massive iceberg). i.e. so that my application code can be used by Spring or  
Guice IoC
containers without having to double-annotate everything (using JSR 250 and  
Guice
annotations) or using JSR 250 annotations then forcing producer methods for  
every
class I write to be written by users using Guice.

It might not be the ideal solution - if you could dictate Guice everywhere  
on a
project then using the Guice specific annotations might be better - but  
given the
pragmatic real world I work in - its a fundamental requirement. These IoC  
container
agnostic annotations have been around for years, supported by all the IoC  
frameworks
I see users & customers already using (e.g. Spring/JBoss/GlassFish and even  
J2EE
servers). Its really a no brainer supporting them. Sure the Guice  
annotations might
be better - if you can assume that all your user base will only ever be  
using Guice
as the IoC container - but thats not really my point here. I'm 100% happy  
for folks
to use guice specific annotations when they can (when they own the  
application code
and choose the IoC container).

Right now the only IoC container I'm aware of which refuses to allow such a  
heretical
idea as supporting the standard set of IoC annotations in widespread use  
today is
Guice. Despite providing a relatively simple patch to fix this show stopper  
4 months
ago - I'm told I must wait for Guice 2 (its been 2 years in the making so  
far - no
idea when it might turn up) and then after that for Guice 3 (in what, 2-4  
years
time?) when this show stopper issue *might* be addressed?

So my choice today is - forget all about Guice, carry on using Spring  
JavaConfig (no
XML, kinda guicy-ish, pretty good - works with any annotations the  
developer (rather
than the guice committer) chooses to use and comes out of the box with JSR  
250/EJB3
support baked in) and carry on working - or sit on my hands and wait 2-4  
years for
Guice 3 and maybe, that might be usable. I think you can see why Spring  
JavaConfig is
my IoC container of choice until Guice 3 turns up.

Hey good luck - Guice is a good piece of work and I wish it well. I hope at  
some
point something vaguely like my patches
(http://code.google.com/p/guiceyfruit/wiki/GuicePatches) do get applied so  
at some
point I could consider Guice for a project - but I'm not holding my breath  
and I
suspect quite alot of other potential guice users won't be either.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"google-guice-dev" 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-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to