1:21 p.m.
Pete,
So, I've always treated Nonbinding as not binding against the parameter,
treating separate values as separate qualifiers. When using a producer, you
end up needing separate producers for each value that you want to support.
This thought is roughly what I was trying to dive through.
John
On Thu, Sep 8, 2011 at 12:19 PM, Pete Muir <pmuir(a)redhat.com> wrote:
Oh yes, let me redo it ;-)
@Retention(RUNTIME)
@interface Foo {
String bar();
}
And use it:
@RequestScoped
class A {
/// Illegal
@Inject InjectionPoint ip;
}
class B {
@Inject @Foo(bar="baz") A a;
}
class C {
@Inject @Foo(bar="qux") A a;
}
And then let's say we have:
@RequestScoped
class D {
@Inject C c;
@Inject B b;
}
On 8 Sep 2011, at 12:15, John D. Ament wrote:
> I think something's wrong with your example, but I think I get what you
mean.
>
> My point is that if Foo were a qualifier and not just an annotation,
should they really be the same injected instance?
If "bar" was binding, it would be a different instance, if bar was non
binding, it would be the same instance.
> It seems like @Nonbinding when used in @RequestScoped is irrelevant,
It's not really relevant or irrelevant, it's just orthogonal. @Nonbinding
affects type bean resolution, which is an orthogonal concept to scoping of
beans.
But a non binding attribute is still non binding when used with
@RequestScoped.
> but i'm not sure the spec makes this clear (though in actuality I'm
against that idea that it wouldn't work).
I think we still have a mismatch in understanding here, as really
@Nonbinding has nothing to do with scoping, which is why the spec doesn't
call this out.
>
> On Thu, Sep 8, 2011 at 11:59 AM, Pete Muir <pmuir(a)redhat.com> wrote:
> No.
>
> Continuing my example, I introduce some new annotation (not a qualifier):
>
> @Retention(RUNTIME)
> @interface Foo {
>
> String bar();
>
> }
>
> And use it:
>
> @RequestScoped
> class A {
>
> /// Illegal
> @Inject InjectionPoint ip;
>
> }
>
> class B {
>
> @Inject @Bar("baz") A a;
>
> }
>
> class C {
>
> @Inject @Bar("qux") A a;
>
> }
>
> And then let's say we have:
>
> @RequestScoped
> class D {
>
> @Inject C c;
> @Inject B b;
>
> }
>
> The *same* instance of A will be injected into B & C when D is accessed.
The injection points allow access to the Annotated, which reflects two
different injection points.
>
> Not gonna work ;-)
>
>
> On 8 Sep 2011, at 11:40, John D. Ament wrote:
>
> > Pete, Mark,
> >
> > So I get there is no single injection point, however it should be the
case that every injection point is declared the same way, no? E.g. they're
the "same" in the sense that the line of code is the same, but different in
that they exist in different areas.
> >
> > John
> >
> > On Wed, Sep 7, 2011 at 8:38 AM, Pete Muir <pmuir(a)redhat.com> wrote:
> > For a request scoped bean there is not a single injection point, like
there is for dependent beans. Say I have a request scoped bean, Bean A.
> >
> > I have two other beans, of any scope, Bean B and Bean C.
> >
> > If both beans B and C inject A in the same request, then the injection
point for A is both Bean B and Bean C.
> >
> > Furthermore, client proxies mean that bean A is instantiated lazily, to
solve the circular injection problem, and so has no knowledge of it's
injection point when actually created.
> >
> > On 7 Sep 2011, at 01:10, John D. Ament wrote:
> >
> > > CDI Experts
> > >
> > > Was wondering if you could help me understand rationale. In request
scoped objects, when you create a producer method that creates request
scoped instances, why is there no access to the underlying injection point?
> > >
> > > Let's say that you have a qualifier with a single String value
attribute that is nonbinding; let's say @JmsDestination. You have the
following injection points:
> > >
> > > @Inject @JmsDestination("jms/MyQueue") MessageProducer
queueProducer;
> > > @Inject @JmsDestination("jms/MyTopic") MessageProducer
topicProducer;
> > >
> > > In this case, two distinct MessageProducers should be injected. The
CDI container should be able to differentiate the two, since they have
different values on the qualifier. However, CDI disallows this since the
producer methods used to create them would not have access to the injection
point. If a second injection point is found, CDI should return the same
instance.
> > >
> > > I hope it doesn't sound like I'm babbling, but I wanted to put
the
question out there to see if it's something that could be addressed.
> > >
> > > Regards,
> > >
> > > John
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> >
>
>