Upon further consideration, I think we should not add the
getInstance() method to InjectionPoint. First, because:
* it can't return a value when constructor injection is happening,
* it always returns an object in an undefined state,
* I have not been able to think of a compelling usecase,
* it places subtle restrictions on implementations of Bean, and
* we're starting to use InjectionPoint as a *static* metadata API so
it would have to be moved anyway.
Does anyone disagree with this decision?
On Wed, Dec 24, 2008 at 5:40 PM, Gavin King <gavin(a)hibernate.org> wrote:
---------- Forwarded message ----------
From: Matt Drees <matt.drees(a)gmail.com>
Date: Sun, Nov 16, 2008 at 4:25 PM
Subject: Injection point metadata API
To: Gavin King <gavin(a)hibernate.org>, Java Community Process JSR #299
Expert List <JSR-299-EG(a)jcp.org>
I really really liked the feature Gavin talked about here:
http://relation.to/Bloggers/InjectionPointMetadataAPIForWebBeans
I think there are some very cool possibilities this opens up for
framework developers and application utility libraries. IMO, this is
a low-cost, high yield feature.
Two other thought about this.
First, I think it'd be nice to add a method to Manager:
public interface Manager {
public <T> T getInstance(Bean<T> bean, InjectionPoint injectionPoint);
...
}
This way if a framework ever has to manually inject objects into a
non-WebBean, a @Current InjectionPoint can be made available to the
injected object.
Second, maybe the InjectionPoint could also be made available to the
Context during a lookup? This way custom pseudo-scopes can be much
more interesting. I haven't thought about this enough, but it sounds
cool. :-)
What do you think?
-Matt
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org