Inject the InjectionPoint

[GoogleCodeExporter]

So they know who they're creating an instance for.

Original issue reported on code.google.com by crazybob...@gmail.com on 25 Feb 2007 at 10:38

[GoogleCodeExporter]

@Inject Injectee injectee; is really confusing though. :(  Don't know what to do
about this.  I think the name InjectedElement may be better than Injectee, but 
that
doesn't really solve this problem.

Original comment by kevin...@gmail.com on 28 Feb 2007 at 7:09

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 8 Mar 2007 at 9:55

• Added labels: 1.1

[GoogleCodeExporter]

Let's design this thing.  First, I think the name Injectee has just gotta go.

interface InjectionPoint {
  Member getMemberBeingInjected();
  Annotation getBindingAnnotation();
  Set<Annotation> getAllAnnotations();
}

?

For parameter injections, getAllAnnotations() would be a union of those on the
parameter and those on the member.  I think getBindingAnnotation() can be
tremendously useful; in the Module I'd simply bind it by type only, then in my
Provider I can do all manner of different things based on its values.

Of course... I could ask to have the BindingAnnotation injected directly which 
could
remove the need for me to downcast (I could @Inject WithTimeout 
timeoutAnnotation)
but it's getting head-trippy.

Original comment by kevin...@gmail.com on 13 Mar 2007 at 1:11

[GoogleCodeExporter]

this would be *really* useful to me, is it in any of the builds/branches so far?

Original comment by dha...@gmail.com on 21 Mar 2007 at 4:15

[GoogleCodeExporter]

+10!

Original comment by arikkfir on 4 Apr 2007 at 1:16

[GoogleCodeExporter]

Previously I described offering access to:

  * the field, method or constructor being injected
  * the binding annotation instance, if present
  * all of the annotation instances present, including that one

I've now reconsidered the need for this feature (once issue 49 is completed).

I don't think we want to allow injection behavior to be dependent on whether 
it's a
field or method injection or what the name of the member is or random 
annotations,
etc.  This makes far too many seemingly-innocuous changes become violent.

What makes sense is to be able to provide differently based on the value of that
binding annotation; without having to bind every single possible value 
individually
the way you have to today.  And this capability will be provided by Issue 49.

So at present I am planning to close this issue unless we can hear some really
compelling use cases for things you need to do that this would not enable.

Original comment by kevin...@gmail.com on 3 Jun 2007 at 6:29

• Removed labels: 1.1

[GoogleCodeExporter]

Would  Issue 49 allow binding of Loggers in the
same fashion as is in guice for java.util.logging.Logger ?

Original comment by peter.ki...@gmail.com on 4 Jun 2007 at 10:49

[GoogleCodeExporter]

No, in the case of Logger, there's only one actual binding. All you need is the
injectee information.

Original comment by crazybob...@gmail.com on 4 Jun 2007 at 10:52

[GoogleCodeExporter]

The Logger thing works because of internal tricks that Guice does, and this will
continue to be the case.  You won't be able to do the same thing.  It just 
interacts
way too poorly with scopes.  You can, however, have your binding annotation 
take a
parameter of type Class, and use the convention

  class MyClass {
    @Inject @MyAnnot(MyClass.class) Foo foo;
  }

Original comment by kevin...@gmail.com on 4 Jun 2007 at 11:19

[GoogleCodeExporter]

How is the declaring class any different from the binding annotation's 
attributes
when it comes to reacting badly with scopes?

Original comment by crazybob...@gmail.com on 4 Jun 2007 at 11:23

[GoogleCodeExporter]

This discussion should be happening over in issue 49, not here (this is the 
issue I
want to close as won't fix).

The binding annotation's attributes become part of the Key, and so they get 
scoped
properly.

Original comment by kevin...@gmail.com on 4 Jun 2007 at 11:32

[GoogleCodeExporter]

OK. I still need to catch up.

Original comment by crazybob...@gmail.com on 4 Jun 2007 at 11:37

[GoogleCodeExporter]

#9 is nearly as bad as the boilerplate it is replacing.
Eversince I hace seen log4j and other logging packages one
of the three things that have annoyed me is the need for
redeclaring the class in the incantation of declaring the
logger. The second thing that annoyed me was the forced use
of the factory pattern. The third thing was the need for if enabled
wrappers around the log statement.

Seam provides a Logger that solves all three (at the cost of using
seam ;-). Guice provides a Logger that solves one and two (at the cost
of using java.util.logging). #9 provides a solution for two and three
but not one.

Original comment by peter.ki...@gmail.com on 5 Jun 2007 at 9:48

[GoogleCodeExporter]

I'm somewhat concerned that giving the provider access to the
java.lang.reflect.Member for an injectee would allow providers to add 
non-explicit
behavior in such a way that the injectee is not free to refactor.  (For example,
doing something different depending on the name of the method, whether it's
constructor/method/field injection, or which class or package the injection is
happening in.)  Are there use cases for that, or would providing the 
annotations suffice?

It seems like having a clear rule that injection is based solely on annotations 
and
the bound type would be less likely to result in surprises.

Original comment by bslesinsky on 7 Jul 2007 at 11:57

[GoogleCodeExporter]

I agree with the above comment, that the Key used to select the provider should 
be sufficient for most purposes.

Original comment by jdpatterson on 9 Oct 2007 at 3:15

[GoogleCodeExporter]

I disagree with that this has anything to do directly with Issue 49.   I also
disagree with 14, 15.  

My use case is that I need to create a Scope based on what Swing Component is
requiring the injection.  In detail, what I need is a JInternalFrame Scope. 
Therefore this is of great interest to me.  

I do like what Issue 49 is getting at, if I read and understood right.  I really
think it will put Guice over the top as the premier DI framework if we can 
inject
based on what object, method, package, closure*, block*, thread, or stage is
requiring the injected object.  It would really be powerful if we can also get 
an
injection based on regular expression too. 

(* = not required now, but looks though as if things like closures and various 
other
blocks will be included in future versions of java)

As per the name "injectee", other names that could be used "source", 
"destination",
or "requestor".   My vote is on "source" since it is consistent with the java's
listeners which typically offers a getSource() method.  

Original comment by dh.evolu...@gmail.com on 20 May 2008 at 5:34

[GoogleCodeExporter]

Deprioritizing. This is an interesting feature but it seems to encourage 
fragile code. It's rare that a method needs 
to know the calling method, and I believe this is similar. 

Original comment by limpbizkit on 30 May 2008 at 7:18

• Changed title: Provide "injectee" to custom providers.
• Changed state: New
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by limpbizkit on 30 May 2008 at 7:24

• Changed title: Inject the InjectionPoint

[GoogleCodeExporter]

This is cool!
Runtime injection can be implemented by this feature plus custom provider

Original comment by kobevali...@gmail.com on 24 Nov 2008 at 9:59

[GoogleCodeExporter]

See patch on http://code.google.com/p/google-guice/issues/detail?id=258

note: runtime injection across custom provider

Original comment by jose.ill...@gmail.com on 9 Feb 2009 at 6:48

[GoogleCodeExporter]

Issue 440 has been merged into this issue.

Original comment by sberlin on 25 Apr 2010 at 10:06

[GoogleCodeExporter]

I continue to believe this feature would be a bad idea.  It's simply backwards. 
 It will become even harder to 
reason about your application when things like this can happen.

Original comment by kevin...@gmail.com on 25 Apr 2010 at 10:09

[GoogleCodeExporter]

I understand people may have some reluctance, but I think that Guice has clearly
taken the path of allowing 3rd party providers to enhance what Guice offers. I 
do
really think this feature would be a great step forward in that way. And since 
it
would be purely SPI, I ought to think that people would really know what they 
are
doing with this.

This functionality would clearly be designed for SPI, so used by people who are
supposed to know what they do.

Original comment by ogregoire on 26 Apr 2010 at 9:28

[GoogleCodeExporter]

Issue 412 has been merged into this issue.

Original comment by sberlin on 2 May 2010 at 12:32

[GoogleCodeExporter]

It's been 4 years since the issue was opened, Guice has seen wide use, and the 
general consensus thus far has been to purposely not expose this feature.  It 
makes debugging even harder than it already is (which is the #1 pain point with 
Guice).

Original comment by sberlin on 19 Feb 2011 at 8:23

• Changed state: WontFix