Open GoogleCodeExporter opened 9 years ago
there's a discussion thread about this here :
http://groups.google.com/group/google-
guice/browse_thread/thread/649f1a24c62a2bae
Original comment by james.st...@gmail.com
on 7 Oct 2008 at 3:27
Wow James, I think it is a really smart idea. This kind of puts Guice at the
root of everything. =)
Original comment by latch...@gmail.com
on 8 Oct 2008 at 3:30
LOL - all part of my evil plan, mwa-ha-ha-ha! :-)
Original comment by james.st...@gmail.com
on 8 Oct 2008 at 3:39
This patch is for Guice 2.x, right?
Original comment by anthony....@gmail.com
on 22 Dec 2008 at 2:03
Yes
Original comment by james.st...@gmail.com
on 22 Dec 2008 at 2:04
Can I use this to redefine "Singleton" guice anotation as custom
anotation"MySingleton"?
How can download this patch/fix?
Original comment by jose.ill...@gmail.com
on 6 Feb 2009 at 2:32
This patch only addresses using custom annotations as both a pointcut to inject
new values into (e.g. to annotate
fields/properties/methods) and to allow those annotations to be bound to a
custom ResourceProviderFactory for
providing their value. e.g. to use @Context from JAX-RS or to provide @Resource
in JSR-250 / EBJ3
Its not an attempt to allow custom annotations to replace other Guice
annotations.
Original comment by james.st...@gmail.com
on 6 Feb 2009 at 3:06
Then, this patch allows "custom injects": Custom annotations to injects values
(generated by CustomProviderFactory) on fields/properties/methods.
It´s true?
Original comment by jose.ill...@gmail.com
on 9 Feb 2009 at 6:25
Thats exactly right Jose. So you can create a Module which defines injection
points
using whatever annotations you like; be they standards (JSR 250, EJB3, JAX-WS,
JAX-RS, Servlet 3) or your own application specified injection points - then
associate a provider of values to that injection point. This allows the
provider to
be able to reuse context (such as the field/method name, type or attributes of
the
annotation) to figure out how to create the values.
It also opens up Guice to be a possible dependency injection engine within these
various frameworks (JAX-RS / EJB3 / Servlet 3 etc) rather than framework
developers
having to write their IoC engine.
I'm sure lots of frameworks would be happy to just reuse Guice as their
preferred IoC
implementation - rather than forcing their users to scrap JAX-WS / JAX-RS /
EJB3 /
Servlet 3 and adopt Guice's one true set of annotations - or drop Guice
entirely and
just use Spring (which does provide an easy mechanism to write your own
injection
points).
Original comment by james.st...@gmail.com
on 10 Feb 2009 at 10:26
Frameworks can already do this with Guice source code directly, if they wish.
I'm not sure I see the benefits of
cherry-picking our (current, reflection-based) DI internals and ignoring
everything else.
As for servlets, Guice already injects components quite comprehensively, as of
Guice Servlet 2.0 (see the wiki on
Servlets).
Original comment by dha...@gmail.com
on 10 Feb 2009 at 2:31
Dhanji, so are you basically saying 'fork off' :).
i.e. no way is Guice ever gonna try and be reusable with other frameworks -
you're
only course of action is to fork the Guice source code?
Original comment by james.st...@gmail.com
on 10 Feb 2009 at 3:03
James, your work is fantastic. Keep it up, and I'm intending on taking it all
in for consideration as soon as we
push v2 out the door.
With respect to supporting custom annotations, my complaint is that it
introduces more indirection to Guice,
without adding more value. Tools like IDEs etc. can use our simple static
methods on InjectionPoint.class to
lookup the injection points for a given class. Should we introduce
InjectionPoint Matchers, it's no longer
possible to know the injection points for a class statically - you'll need a
Module to figure them out. I don't
think this is a net win for our users.
I believe a lot of the motivation for custom annotations is people's distaste
for importing 'com.google'
packages into their core classes. But the same people happily import 'java.'
packages everywhere. I think this
is a bit irrational, because Google loves you way more than Sun or the JCP does.
Original comment by limpbizkit
on 10 Feb 2009 at 5:02
@james.strachan
What Jesse said =)
There are loads of implications to supporting any annotation or no modules, and
we want to provide the best
experience for everyone, which I think the current design does very nicely.
...Also I think Provider methods make it really easy to support and reuse other
frameworks. And the new
Servlet module makes it easy to integrate web frameworks like jersey. ;)
Original comment by dha...@gmail.com
on 10 Feb 2009 at 9:58
Limpbizkit, I hate APOJOs (Annotated POJOs) and Anotations of any owner:
'java(x).',
'com.google', 'org.hibernate', ...
I only likes MY custom anotations (@MyTransactional, @MySecure, @MySingleton,
@MyInject) everywhere
Original comment by jose.ill...@gmail.com
on 23 Feb 2009 at 10:57
I highly dislike Jose's request. I think the main point of this RFE is that we
should
be able to integrate with existing annotations used by other frameworks. The
fact
that this also allows one to implement Jose's request is a side-effect but (my 2
cents) we shouldn't go out of our way to allow individual users to define their
own
annotations just for the sake of not having Guice's package name show up in
their
imports. It's a complete waste of our time.
So +1 for James' idea and -1 for Jose. Sorry.
Original comment by gili.tza...@gmail.com
on 24 Feb 2009 at 12:05
@Gili: What is it about Jose's request you "dislike"? Seems like you'd want to
go out
of your way to NOT allow individual users to define their own annotations?!
@limpbizkit: Imagining that your comment about "com.google" being as good a
package
name as "java" wasn't meant as a joke, I find the thought disturbing and silly.
This
particular for such central pieces of technology that IoC has become. The time
has
probably come where one should start striving towards standardization of the
IoC
ideas and obviously also the annotations involved - and such standardization
should
hopefully not be with google as part of the package name. Java shouldn't be an
advertising board!
Original comment by stolsvik
on 24 Feb 2009 at 12:34
Stolsvik,
The complaint about having "foreign" package names in your import list is what
I find
silly about James and your comments. Java isn't a "designed by a committee"
language.
Many "standards" are de-facto standards that have eventually been folded into
the
platform. Even C++ development requires one to #include many non-standard
namespaces
for 3rd-party libraries.
Who cares what the package name is? The vast majority of Java libraries out
there are
*not* by Sun. Nor should they be. Again, I find this whole argument very silly.
The
package name is not an advertisment. According to JLS section 7.7 one is
encourages
to take the company domain name (google.com in this case) and reverse it to
form the
package name. Hence, "com.google". This is no different from sun.com using
"com.sun".
I don't want to come off as an ass, but this entire argument is highly
subjective. I
can't say that you are wrong, just that I personally disagree with your view
for the
reasons I outlined above.
Original comment by gili.tza...@gmail.com
on 24 Feb 2009 at 1:03
Definitely highly subjective, I agree. What about this: You'd then be happy
with
com.ibm.core.String, com.apple.io.Reader, com.bea.net.URL, com.microsoft.URI,
com.sun.URI, com.oracle.Connection, com.mysql.Connection, com.jboss.Math,
com.suse.Remote and so on? That would not annoy you the least?
I think there should be a java core (which should have the java package name).
Innovation often happens outside the standard, but that shouldn't discourage
assimilation of the good stuff into the standard. The IoC idea, and the
refinement of
the idea using annotations, are such good stuff. The point of the core is to
make
interoperability easier. Now we have a situation where several sets of such
annotations exists. Some steps towards solving the problem would be to make
Guice
handle other annotations.
What is somewhat absurd here, is that there apparently already exists a patch
that
would make a diverse bunch of people happy about having other options when it
comes
to annotations, for a diverse set of reasons. But this patch won't even, it
seems, be
looked into. What is the rationale behind this stubbornness?
Limpbizkit says "[custom annotations] introduces more indirection to Guice,
without adding more value". The idea that this doesn't add value is enormously
subjective, IMHO.
Original comment by stolsvik
on 24 Feb 2009 at 1:28
"You'd then be happy with [...]"?
String and URL are bad examples in that they are concrete classes but I get your
point. To answer your question, I would be happy with com.ibm.ArrayList that
implements java.util.List. I would choose to use java.util.List all over my
code (to
remain portable across implementations) but the fact that com.ibm.ArrayList
shows up
in my import statement is just fine.
Furthermore, nothing prevents Guice from implementing standard interfaces in the
future if some official JSR is published. The fact of the matter is that no such
standard exists today so this discussion is moot.
Look at what happened to Hibernate once JPA came out. You can still use the old
Hibernate classes or the new JPA ones. You can even use the two together, they
aren't
mutually exclusive. Another example, Jersey as an implementation of JAX-RS.
When you
use Jersey you end up with both JAX-RS and Jersey import statements. There is no
contradiction there. JAX-RS publishes interfaces. Jersey publishes
implementation
classes.
Original comment by gili.tza...@gmail.com
on 24 Feb 2009 at 1:49
Regarding java.util.List vs. com.ibm.ArrayList: I agree, and I think that
@Inject in
this regard definitely is an interface.
Regarding "no such standard exists today" - read top post.
Regarding Hibernate vs. JPA etc: One may argue that one is there today, and
that
Guice would make more people happy if it supported this seemingly simple
customization option. (Have you read Joel's piece about how Excel won when it
implemented /export/ filters? Maybe something like that would happen here too -
people would feel safer when they COULD get out of google's claws if they
wanted)
IMO, there is no argument about whether Guice is "intrusive". It is: One have
to
annotate the code, specifically importing guice/google-specifics. Spring isn't:
One
use a completely external configuration. This is a bit sad.
Annotating with standard annotations, or failing that, with project-specific
annotations, would be nearly the same as no external dependencies. If several
injection containers implemented the standard annotations, or/and such a
pluggable
annotation processing, one would again be free in that one could change the
container: Either by just changing it (if one used standards), or by doing the
container-specific customization to process the project-specific annotations.
There
is value here - stating otherwise undermines all those success stories of how
one
changed from Spring to Guice in a matter of hours. There is one hurdle left:
The
semantics of the IoC annotations - but at least for simple cases, which most
probably
is the majority, this is probably not very hard.
Original comment by stolsvik
on 24 Feb 2009 at 2:09
I was under the impression that @Resource and other standard annotations do not
cover
the same (or all) functionality exposed by Guice or Spring. Speaking of which,
if
there *is* a standard why doesn't Spring annotations use it either? If we're
going to
compare apples to apples then we should be discussing Spring annotations vs
Guice
annotations (external configuration files fall outside this discussion). As far
as I
know both use proprietary annotations.
Original comment by gili.tza...@gmail.com
on 24 Feb 2009 at 2:22
http://static.springframework.org/spring/docs/2.5.x/reference/new-in-2.html#new-
in-2-
ioc-annotations
http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-
resource-annotation
The semantics are slightly off, but these things are converging. Spring's
annotation
driven IoC processing along with its JavaConfig project makes Guice not the
only kid
on the block with "new style" IoCing. I think Guice should open up wide!
Original comment by stolsvik
on 24 Feb 2009 at 2:38
stolsvik, please embrace the fact that Java uses domain names in imports.
You've also criticized the package
name in Glazed Lists, and it's getting extremely tiresome. Your application's
users would prefer for you to focus
on features and bugs.
Original comment by limpbizkit
on 24 Feb 2009 at 8:15
Gili - its a shame you think my comments are silly though I'm not exactly sure
what
it was you were referring to.
FWIW my motivation for this patch was not because I dislike using com.google.*
- its
that I like being able to support *existing* popular standards like JSR 250 /
EJB3
annotations (e.g. @Resource / @PreDestroy / @PostCommit) which are very widely
used.
They are the nearest thing we have to IoC standards right now. (@Resource is
kinda a
standard version of guice's proprietary @Name). Most popular standards define
some
kind of IoC annotations these days (JSR 250, EJB3, JPA, JAX-RS, JAX-WS,
WebBeans etc).
If you work solely inside your corporate firewall and don't have to share code
with
customers you probably don't care about standards - but many of us outside the
googleplex do I'm afraid and for something as pervasive at so many layers as IoC
standards are a good thing IMHO.
FWIW many other IoC containers have supported these annotations for *years*
(e.g.
Spring) as well as letting anyone, easily add any kind of annotation processor
to
encourage innovation.
For some reason supporting standards that people actually use seems kinda
against the
insular Not Invented Here Google way. Looks like its Spring and JavaConfig for
me
going forward (which is pretty good too - and fully supports JSR 250 & EJB3
already
and is super easy to extend to support custom annotation injections).
Its a shame as Guice was really close to being a contender as a really popular
IoC
framework outside of Google. Fingers crossed for Guice 3 in, what, 2012? Though
I've
a feeling it'll be game over by then and folks will just use Spring JavaConfig
(assuming Java is still popular by then :)
Original comment by james.st...@gmail.com
on 24 Feb 2009 at 10:01
James,
I'm sorry if I misunderstood your comments. I am all in favor of reusing
standard
annotations (such as @Resource) if possible.
Original comment by gili.tza...@gmail.com
on 24 Feb 2009 at 1:28
@limpbizkit: Glazed Lists uses a coding, java and computers-unrelated domain
name of
a weapons-touting company. I have never shown any intent on /not/ having a
domain-
name in GlazedLists, but why not use [com|org|net].glazedlists, all of which
actually
are available, instead of a BLOODY GUNS'n'AMMO COMPANY??
You are //completely// derailing the discussion, and of course you know it.
I do not, in any way, want you to take away com.google from the system aspects
of
Guice (that is actually slightly cool!), but I want you to make it possible for
the
annotations, and hence my and others' code, to not be bound to Google's
specific
annotations. This I have been clear about in this and other bugs' discussion
all the
time.
So DO NOT put completely baseless meanings into my mouth.
I cannot comprehend why it is problematic for you Googlers to understand that
not
everyone is happy with having all their code, and all others' code, be "bound
to
Google" via Guice's annotations. I actually don't mind very much that my own
code has
these annotations, but I find it a huge problem that any future
"IoC-compatible" code
that I take into my project will have to be Guice specific. (and yes, one have
Providers, but that's rather beside the point in this discussion)
Spring does not force you to such measures, in any way, and never has - that
was its
main idea! Guice probably got a huge migration from Spring, due to the
innovative
thoughts by Bob embedded in the system. But if you don't consider your users'
whishes
nor code submissions, while Spring copies all the innovation back again (only,
as
always, not trying to do a lock-in on you), I know you will have a migration
back.
From a bit more abstract view: One big point of the entire IoC stuff was that
one
could write "POJOs", without dependencies on any container-specifics, and use
an
external tool to stitch these together. This made the code completely container-
unaware, and all of a sudden one could just code, and pick the container
afterwards,
or at least not be bound to a specific container (or just wire them yourself,
as in
testing). Guice showed that using annotations, and using java to do the wiring,
gave
quite a bit of type safety and refactorability, both missing very much from
Spring's
XML hell. But this came at price - now your supposedly POJOs are again
implementing a
/specific/ container's "interface": The Google annotations. This will probably
hurt
both the emergence of open source, or otherwise free, generically IoC-annotated
code,
and possibly the adoption of Guice once more and more developers figure these
facts
out themselves.
Original comment by stolsvik
on 24 Feb 2009 at 2:00
@james.strachan please don't leave us! It's easy to use third-party
annotations, or XML, or whatever you like,
on top of Guice. For a cute example, see the XML code Bob recently checked into
the core source tree.
Guiceyfruit is awesome and I hope you continue it. And I'm intending to review
your patch as soon as we push
Guice 2 out-the-door. Naturally, that's taken much longer than I'd anticipated,
and the delay is making me
quite sad. We want to make you happy, you're one of the best contributors in
our small community.
I'm fairly skeptical of arguments that say "import javax.*" is good, but
"import com.*" is bad, mostly because
there's a lot of extremely good code that starts with "com" and also a lot of
extremely bad code that starts
with "javax".
Original comment by limpbizkit
on 24 Feb 2009 at 5:49
Jesse,
I think we've all misunderstood James' point. He doesn't object to the package
names
but rather to the difficulty of migrating across different IoC implementations.
If
the standard @Resource annotation is "good enough" to cover the Guice
implementation
why *shouldn't* we be using it instead of defining our own? That is, Guice
should use
existing annotations/interfaces as much as possible instead of generating our
own
(again, when it is reasonable).
Original comment by gili.tza...@gmail.com
on 24 Feb 2009 at 6:13
@limpbizkit this is not sun(java.*) vs google(com.google.*) war
@gili you really misunderstood me
@james GREAT work
I loves Guice Interceptor, based on customs annotations allows me define:
@Transactional: add transactions to any method
@Secure({Role1, Role2}): adding authorization based on role list
But, If I like to change quickly between guice/spring/other? (without lost
amounts of
time) custom annotations is the only exit (IMO)
note: custom = any
Nobody can say: "I use *** framework in the future"
Original comment by jose.ill...@gmail.com
on 24 Feb 2009 at 10:09
It seems like there are two issues here:
1) standardizing on common names for things (e.g. naming injection points)
2) the code that implements this standard.
Guice is both a (de-facto) standard and an implementation. If you're not using
Guice's annotations, you're not following the Guice standard, but rather some
other
standard. It seems perfectly reasonable for someone to write code to some other
standard and even to embed the Guice core into a dependency engine for some
other
standard, but we don't want to confuse people about what the Guice standard
actually
is. It should be obvious that you're doing something non-standard (from Guice's
point
of view).
Original comment by bslesinsky
on 25 Feb 2009 at 3:04
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.
Original comment by james.st...@gmail.com
on 25 Feb 2009 at 9:15
I agree 100% with James' comments, but have far far less patience than he does.
I'v jumped off the guice ship months ago, and whenever asked, I recommend that
people avoid it.
The reasoning is exactly the same as James'. The constant refusal to add
support for annotations that are in use by everyone, require no new knowledge,
that have become commonplace
everywhere else is perplexing, to say the least. The argument that javax.* is
bad code and com.* is good code is....and I'm putting this in the most polite
way I know...idiotic, moronic,
and ignorant. Have you any idea how much bad com.* code is out there? However,
I won't get sidetracked by addressed such a silly claim, and will stick to the
point at hand.
It's perplexing to me that after being assured a year or two ago that Guice
will provide infrastructure to support these common annotations, the solution
now has gone to 'sorry, we don't
trust them'. Even the Guice BOF at JavaOne last year made comforting noises
about the ability to support custom annotations via listeners. In fact, I'm
fairly sure that I've filed an issue
more or less after the first first Guice public preview stating the need for
these annotations.
It's become abundantly clear that Guice's priorities are much the same as
Google's priorities when it comes to open source that it uses in house, Google
first, and if that happens to
benefit the community incidentally, then that's great, if not, then that's
great too.
You keep wondering why people care, and the answer is simple. It's less to
learn, it lowers the barrier to entry, and saves you a few extra seconds of
thinking 'now how do I do the thing
I've been doing for months elsewhere...' I work with a lot of developers, and
now they're all comfortable with things like @PreConstruct @Resource,
@TranasactionAttribute, and so on.
There's no sane reason why they should now have to learn another set of
annotations that perform the exact same role if they ever want to use Guice, or
even worse, being told that
'sorry, that model is not even possible, you need to think differently and
pretend like Guice has it all figured out'. It reminds me of when the
picocontainer guys refused to do setter
injection, claiming constructor injection is the only way to go. Look at where
pico is now.
See, the community is perfectly happy for you to maintain your elitist selfish
attitude to the codebase, and your refusal to add features that don't
personally benefit you. It's the Guice
way, and that's totally fine. What's infinitely more frustrating is your
refusal to add extensions to enable other people to do what they need to do.
Fine, don't add support for standard
annotations if they insult your purist insular view of the world, but give us
annotation listeners or whatever other infrastructure so that the rest of us
who work in the real world can deal
with such dirty concepts as javax.* code.
Original comment by bileb...@gmail.com
on 25 Feb 2009 at 1:02
I'm convinced.
Sincere apologies for being ivory-tower with my previous arguments. I've
certainly underestimated how
urgently this patch is desired. That's my own fault.
I didn't fully understand the motivation behind this patch. I foolishly assumed
people wanted to use
@Resource because it was more pure to use a javax.* API than a com.google API.
Of course, the real issue is
that you've already got thousands of lines of code that already use @Resource
etc., and you'd like to use that
code with Guice. And I didn't realize how painful/impossible/unpleasant it is
be for you all to add @Inject to
existing code.
Also, when I said "after 2.0" what I really meant was "immediately after 2.0".
Adding new functionality like this
can destabilize, and I wanted to first release what we already have.
Unfortunately, I was originally intending to
release 2.0 six months ago, but the release has been delayed. I'm currently
polishing up the docs so we can
push it out ASAP.
Hani, we've done a lot of work to make Guice work better for the community
outside of Google, and it makes
me sad to see you say otherwise. In particular, OSGi and Maven support are
exclusively for the benefit of the
community, and they've both taken quite a bit of work.
Original comment by limpbizkit
on 25 Feb 2009 at 5:11
Awesome! :) Many thanks!
Original comment by james.st...@gmail.com
on 25 Feb 2009 at 6:06
Well, that's a relief!
I still though am grumpy about the lack of 2.0, it's just so much stuff
promised, but very little delivered (that I
can see).
I do hope you get 2.0 out before the boat has passed though, and will
definitely revisit once some of these
features make it in.
Original comment by bileb...@gmail.com
on 25 Feb 2009 at 11:37
hooray, everyone is happy again.
Also, let's not forget servlet support, which is for the community as much as
it is for us internally.
I think it's worth appreciating Jesse a little as he's worked extremely hard to
make this happen. It may appear
that there's been no commit activity on Guice for weeks, but what you don't see
is Jesse working diligently to get
Guice tested against all of our internal projects, which are numerous and vast
to say the least.
Original comment by dha...@gmail.com
on 26 Feb 2009 at 12:48
@bileblog Guice 2 has been stable and available for quite some time, available
from
SVN. We took a leap of faith and pulled down a snapshot of it and use that
internally. I really look forward to using an official 2.0 though.
Kudos to everyone, google, contributors, and everyone here providing input. I'm
glad
to see people communicating and listening.
Original comment by mark.ren...@gmail.com
on 26 Feb 2009 at 2:01
James, you rock. We really appreciate the contributions. We won't let you
down--we'll
make sure construction listeners (or something comparable) makes it into Guice 2
which is coming *very soon* thanks to Jesse's tireless efforts. I know how much
of a
pain maintaining external patches can be.
My single biggest regret about Guice 1 is that I didn't rename the package to
"guice"
when I open sourced it. Too late now though.
I could go on about the tragedy in "Java standard" becoming synonymous with
"JCP",
but I won't. :-)
Original comment by crazybob...@gmail.com
on 26 Feb 2009 at 6:24
Smile on your brother everybody get together gotta love one another right now.
Original comment by michael....@gmail.com
on 27 Feb 2009 at 2:35
@james: one more thing...
It's necesary a Module "binding"?
for example:
binder.<bindInjectorProvider>(@Resource, ResourceProviderFactory.class);
note: this allows me configure providers on my Module
Original comment by jose.ill...@gmail.com
on 27 Feb 2009 at 11:58
@jose: Great point! I've gone ahead and implemented that now BTW.
e.g. using the GuiceyFruit library (http://code.google.com/p/guiceyfruit/)
using the current trunk of Guice you can do things like this...
bindAnnotationInjector(Resource.class, ResourceMemberProvider.class);
For more detail see the JSR 250 module:
http://code.google.com/p/guiceyfruit/source/browse/trunk/guiceyfruit-
core/src/main/java/org/guiceyfruit/jsr250/Jsr250Module.java
Original comment by james.st...@gmail.com
on 3 Apr 2009 at 9:47
BTW we can mark this issue closed now IMHO!
There's everything you need in Guice trunk now to implement any kind of custom
injection strategy.
e.g. here's an example of it in use
http://tinyurl.com/ch8u4q
http://code.google.com/p/guiceyfruit/source/browse/trunk/guiceyfruit-
core/src/main/java/org/guiceyfruit/jsr250/Jsr250Module.java
and here's how the code works (just a few simple helper methods on standard
Guice)
http://tinyurl.com/cp9q9g
http://code.google.com/p/guiceyfruit/source/browse/trunk/guiceyfruit-
core/src/main/java/org/guiceyfruit/support/GuiceyFruitModule.java
Original comment by james.st...@gmail.com
on 3 Apr 2009 at 9:52
James, thank you.
Original comment by limpbizkit
on 4 Apr 2009 at 12:47
Will there be a 2.0-beta-6 release soon (including these patches)?
Because the last snapshot is dated October 22, 2008!
Thanks
Original comment by christia...@gmail.com
on 6 Apr 2009 at 9:50
@christian: are you talking about guice or guiceyfruit (only the last
guiceyfruit
release was 2.0-beta-5 which has the above patches included which made me think
you
were talking about that).
There should be a 2.0-beta-6 release of guiceyfruit cut this week with Spring
annotations support too... I can't speak for the guice folks though and their
release
cycle.
Original comment by james.st...@gmail.com
on 6 Apr 2009 at 10:47
@james: I was talking about GuiceyFruit...
I was wondering because it seems there's no nightly builds available, the
snapshot
repo is outdated...
Thanks James!
Original comment by christia...@gmail.com
on 7 Apr 2009 at 6:18
@christian the 2.0-beta-6 release of GuiceyFruit is now out btw!
http://code.google.com/p/guiceyfruit/wiki/Download
Original comment by james.st...@gmail.com
on 14 Apr 2009 at 10:55
@james: GREAT PATCH!!
@limpbizkit: When add this patch on Guice?
Thank you
Original comment by jose.ill...@gmail.com
on 6 May 2009 at 1:50
Original issue reported on code.google.com by
james.st...@gmail.com
on 7 Oct 2008 at 3:13Attachments: