3:05 a.m.
The spec requires that injection points be validated at init time for
any Bean (for XxxxxDependencyException).
Nick from the RI team has noticed that for this to be implementable,
we need to add metadata about the injection points of a bean to the
Bean interface.
I propose:
public abstract class Bean<X> {
...
Set<InjectionPoint> getInjectionPoints();
}
Since we already have the following interface that describes injection points:
public interface InjectionPoint {
public Type getType();
public Set<Annotation> getBindingTypes();
public Object getInstance();
public Bean<?> getBean();
public Member getMember();
public <T extends Annotation> T getAnnotation(Class<T> annotationType);
public Annotation[] getAnnotations();
public boolean isAnnotationPresent(Class<? extends Annotation> annotationType);
}
I will make this change to the spec, unless anyone speaks up with any objection.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
9:07 a.m.
New subject: [webbeans-dev] Re: Bean.getInjectionPoints()
On Dec 30, 2008, at 1:35 PM, Gavin King wrote:
The spec requires that injection points be validated at init time
for
any Bean (for XxxxxDependencyException).
Nick from the RI team has noticed that for this to be implementable,
we need to add metadata about the injection points of a bean to the
Bean interface.
It shouldn't be necessary, since "SimpleBean implements Bean" should
be responsible for its own validation. It doesn't make sense for the
Manager implementation to validate the Bean, since that breaks the
encapsulation model of both Manager and Bean. It's cleaner for
Manager to assume the Bean is valid.
On a related note, it would be cleaner if the Bean.create() method was
changed to Bean.create(Context) in order to handle circular references.
The logic of Bean.create(Context) would be
1. check if Bean is in Context (for circular ref), if so return the
bean.
2. instantiate the Bean (do not inject/initialize) and put it in
Context (so we have a ref)
3. inject/initialize the bean as usual (this may trigger the
circular reference, which would be resolved by #1 on a second call).
-- Scott
I propose:
public abstract class Bean<X> {
...
Set<InjectionPoint> getInjectionPoints();
}
Since we already have the following interface that describes
injection points:
public interface InjectionPoint {
public Type getType();
public Set<Annotation> getBindingTypes();
public Object getInstance();
public Bean<?> getBean();
public Member getMember();
public <T extends Annotation> T getAnnotation(Class<T>
annotationType);
public Annotation[] getAnnotations();
public boolean isAnnotationPresent(Class<? extends Annotation>
annotationType);
}
I will make this change to the spec, unless anyone speaks up with
any objection.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
9:59 a.m.
New subject: [webbeans-dev] Re: Bean.getInjectionPoints()
On Fri, Jan 2, 2009 at 2:37 PM, Scott Ferguson <ferg(a)caucho.com> wrote:
On Dec 30, 2008, at 1:35 PM, Gavin King wrote:
> The spec requires that injection points be validated at init time for
> any Bean (for XxxxxDependencyException).
>
> Nick from the RI team has noticed that for this to be implementable,
> we need to add metadata about the injection points of a bean to the
> Bean interface.
It shouldn't be necessary, since "SimpleBean implements Bean" should be
responsible for its own validation. It doesn't make sense for the Manager
implementation to validate the Bean, since that breaks the encapsulation
model of both Manager and Bean. It's cleaner for Manager to assume the Bean
is valid.
That only works for Bean implementations provided in the
specification. It does not work for Bean implementations provided by
3rd-party extensions. We need the dependency validation stuff to work
in the second case also.
On a related note, it would be cleaner if the Bean.create() method
was
changed to Bean.create(Context) in order to handle circular references.
The logic of Bean.create(Context) would be
1. check if Bean is in Context (for circular ref), if so return the bean.
2. instantiate the Bean (do not inject/initialize) and put it in Context
(so we have a ref)
3. inject/initialize the bean as usual (this may trigger the circular
reference, which would be resolved by #1 on a second call).
Bean already has a reference to the Manager and can call
Manager.getContext(myScope). So the extra parameter would not be
necessary.
But what you're really saying is that it's better to handle circular
references from Bean.create() than from Manager.getInstance(). OK,
that's really interesting, let me chat to Pete Muir about that and get
back to you.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
10:12 a.m.
New subject: [webbeans-dev] Re: Bean.getInjectionPoints()
On Fri, Jan 2, 2009 at 3:29 PM, Gavin King <gavin(a)hibernate.org> wrote:
But what you're really saying is that it's better to handle
circular
references from Bean.create() than from Manager.getInstance().
I expressed myself badly here. What I mean is:
The responsibility for associating the new object with the Context
should be in Bean.create() instead of in Context.get().
This is not quite as simple as it sounds because it means adding a
Context.put() operation, with hard-to-define semantics, and some way
of ensuring that instances for which injection is not yet complete are
not visible to other threads executing in the same context.
Actually I think there is a better way to solve the problem, but I
need to talk it over with Pete.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
10:49 a.m.
New subject: [webbeans-dev] Re: Bean.getInjectionPoints()
On Fri, Jan 2, 2009 at 3:42 PM, Gavin King <gavin(a)hibernate.org> wrote:
Actually I think there is a better way to solve the problem, but I
need to talk it over with Pete.
The alternate solution is something like:
interface CreationalContext {
void add(Bean<X> bean, X instance); //registers an "incomplete"
instance
}
interface Contextual<T> {
public abstract T create(CreationalContext ctx);
...
}
interface Context {
public <T> T get(Contextual<T> bean); //get any existing instance
public <T> T get(Contextual<T> bean, CreationalContext ctx);
//get or create an instance
public Class<? extends Annotation> getScopeType();
boolean isActive();
}
interface Manager {
Object getInstanceToInject(CreationalContext ctx,
InjectionPoint ij, Type type, Annotation... bindings);
...
}
And getInstanceToInject() would be smart enough to return any object
that had already been registered with the CreationalContext.
Note that this solution addresses the problem of circular references,
and also fixes a hole in how the Manager knows about the
InjectionPoint.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
10:52 a.m.
New subject: [webbeans-dev] Re: Bean.getInjectionPoints()
On Jan 1, 2009, at 8:29 PM, Gavin King wrote:
>
> It shouldn't be necessary, since "SimpleBean implements Bean"
> should be
> responsible for its own validation. It doesn't make sense for the
> Manager
> implementation to validate the Bean, since that breaks the
> encapsulation
> model of both Manager and Bean. It's cleaner for Manager to assume
> the Bean
> is valid.
That only works for Bean implementations provided in the
specification. It does not work for Bean implementations provided by
3rd-party extensions. We need the dependency validation stuff to work
in the second case also.
The validation would be a requirement on the extension, which should
be reasonable since a new Bean type would be a relatively rare and
sophisticated thing. If a 3rd party is capable of introspecting the
injection points, it's fully capable of calling the Manager methods
for validation.
Mostly, though, it's an encapsulation issue. The proposal exposes and
constrains information that really should be internal to the Bean
implementation just for the purpose of a relatively straightforward
validation.
> On a related note, it would be cleaner if the Bean.create()
method
> was
> changed to Bean.create(Context) in order to handle circular
> references.
>
> The logic of Bean.create(Context) would be
> 1. check if Bean is in Context (for circular ref), if so return the
> bean.
> 2. instantiate the Bean (do not inject/initialize) and put it in
> Context
> (so we have a ref)
> 3. inject/initialize the bean as usual (this may trigger the circular
> reference, which would be resolved by #1 on a second call).
Bean already has a reference to the Manager and can call
Manager.getContext(myScope). So the extra parameter would not be
necessary.
True, but I did like the old DependentScoped concept of the previous
draft, and that kind of scope isn't available from the Manager. (I'm
not exactly sure why the dependent concept changed between drafts. I
assumed the new way was easier to define.)
But what you're really saying is that it's better to handle
circular
references from Bean.create() than from Manager.getInstance(). OK,
that's really interesting, let me chat to Pete Muir about that and get
back to you.
...The responsibility for associating the new object with the Context
should be in Bean.create() instead of in Context.get().
Right. It's easier to manage the circular problem there, or at least
was easier for me.
This is not quite as simple as it sounds because it means adding a
Context.put() operation, with hard-to-define semantics, and some way
of ensuring that instances for which injection is not yet complete are
not visible to other threads executing in the same context.
That's a good point. Although, I'd think the visibility issue would
exist with any API that supported circular refs, and the circular ref
issue is important. Certainly for ApplicationScoped services.
-- Scott
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
11:03 a.m.
New subject: [webbeans-dev] Re: Bean.getInjectionPoints()
On Fri, Jan 2, 2009 at 4:22 PM, Scott Ferguson <ferg(a)caucho.com> wrote:
> That only works for Bean implementations provided in the
> specification. It does not work for Bean implementations provided by
> 3rd-party extensions. We need the dependency validation stuff to work
> in the second case also.
The validation would be a requirement on the extension, which should be
reasonable since a new Bean type would be a relatively rare and
sophisticated thing. If a 3rd party is capable of introspecting the
injection points, it's fully capable of calling the Manager methods for
validation.
But the problem is that it doesn't know *when* to validate. Validation
can't be performed until *all* Beans have been registered.
Hum, I now see that there's a problem with the current definition of
the @Initialized Manager event - it actually needs to happen *before*
deployment problems are validated and thrown. Or perhaps there should
be two events? @Initialized Manager and @Deployed Manager.
Lucky we didn't let that sip through!
Mostly, though, it's an encapsulation issue. The proposal
exposes and
constrains information that really should be internal to the Bean
implementation just for the purpose of a relatively straightforward
validation.
But given that this validation stuff is *so* central to what Web Beans
is and does, I think the Manager should provide this functionality
automagically. Hey, nothing prevents the Bean implementation from
returning an empty Set if they want to do their own validation....
True, but I did like the old DependentScoped concept of the previous
draft,
and that kind of scope isn't available from the Manager. (I'm not exactly
sure why the dependent concept changed between drafts. I assumed the new
way was easier to define.)
The new way is harder, actually. The problem with the old definition
was that if you had two injection points of the same type, in the same
object, you got the same instance, which was not really useful to
anyone. (There was some other problem too, IIRC.)
> But what you're really saying is that it's better to
handle circular
> references from Bean.create() than from Manager.getInstance(). OK,
> that's really interesting, let me chat to Pete Muir about that and get
> back to you.
>
> ...The responsibility for associating the new object with the Context
> should be in Bean.create() instead of in Context.get().
Right. It's easier to manage the circular problem there, or at least was
easier for me.
Check my most recent email.
12:24 p.m.
New subject: [webbeans-dev] Re: Bean.getInjectionPoints()
Hi;
Actually the spec requires to return Proxy objects from the Manager.getInstance(). So the
dependency injection does not occur until Bean method is called, i.o.w Context.get() is
not called before the any method calls on the Bean.
So, circular reference may not be happened with Proxy usage.
Gurkan
________________________________
From: Gavin King <gavin(a)hibernate.org>
To: Scott Ferguson <ferg(a)caucho.com>
Cc: Michael Keith <michael.keith(a)oracle.com>; WebBeans
<webbeans-dev(a)lists.jboss.org>; Java Community Process JSR #299 Expert List
<JSR-299-EG(a)jcp.org>
Sent: Friday, January 2, 2009 6:29:46 AM
Subject: Re: [webbeans-dev] Re: Bean.getInjectionPoints()
On Fri, Jan 2, 2009 at 2:37 PM, Scott Ferguson <ferg(a)caucho.com> wrote:
On Dec 30, 2008, at 1:35 PM, Gavin King wrote:
> The spec requires that injection points be validated at init time for
> any Bean (for XxxxxDependencyException).
>
> Nick from the RI team has noticed that for this to be implementable,
> we need to add metadata about the injection points of a bean to the
> Bean interface.
It shouldn't be necessary, since "SimpleBean implements Bean" should be
responsible for its own validation. It doesn't make sense for the Manager
implementation to validate the Bean, since that breaks the encapsulation
model of both Manager and Bean. It's cleaner for Manager to assume the Bean
is valid.
That only works for Bean implementations provided in the
specification. It does not work for Bean implementations provided by
3rd-party extensions. We need the dependency validation stuff to work
in the second case also.
On a related note, it would be cleaner if the Bean.create() method
was
changed to Bean.create(Context) in order to handle circular references.
The logic of Bean.create(Context) would be
1. check if Bean is in Context (for circular ref), if so return the bean.
2. instantiate the Bean (do not inject/initialize) and put it in Context
(so we have a ref)
3. inject/initialize the bean as usual (this may trigger the circular
reference, which would be resolved by #1 on a second call).
Bean already has a reference to the Manager and can call
Manager.getContext(myScope). So the extra parameter would not be
necessary.
But what you're really saying is that it's better to handle circular
references from Bean.create() than from Manager.getInstance(). OK,
that's really interesting, let me chat to Pete Muir about that and get
back to you.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
12:30 p.m.
New subject: [webbeans-dev] Re: Bean.getInjectionPoints()
GK >>The responsibility for associating the new object with the Context
GK>>should be in Bean.create() instead of in Context.get().
I think how to implement Bean and Context contract of the spec. is left to the
implementations. This may not be required by the spec itself.
Gurkan
________________________________
From: Gavin King <gavin(a)hibernate.org>
To: Scott Ferguson <ferg(a)caucho.com>
Cc: Michael Keith <michael.keith(a)oracle.com>; WebBeans
<webbeans-dev(a)lists.jboss.org>; Java Community Process JSR #299 Expert List
<JSR-299-EG(a)jcp.org>
Sent: Friday, January 2, 2009 6:42:39 AM
Subject: Re: [webbeans-dev] Re: Bean.getInjectionPoints()
On Fri, Jan 2, 2009 at 3:29 PM, Gavin King <gavin(a)hibernate.org> wrote:
But what you're really saying is that it's better to handle
circular
references from Bean.create() than from Manager.getInstance().
I expressed myself badly here. What I mean is:
The responsibility for associating the new object with the Context
should be in Bean.create() instead of in Context.get().
This is not quite as simple as it sounds because it means adding a
Context.put() operation, with hard-to-define semantics, and some way
of ensuring that instances for which injection is not yet complete are
not visible to other threads executing in the same context.
Actually I think there is a better way to solve the problem, but I
need to talk it over with Pete.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
12:35 p.m.
New subject: [webbeans-dev] Re: Bean.getInjectionPoints()
Just my comment:
For adding the new API for this complicates the specification.
I think, specification provides the necessary API related with Bean creation. As I said,
these concerns are left to the implementations.
Gurkan
________________________________
From: Gavin King <gavin(a)hibernate.org>
To: Scott Ferguson <ferg(a)caucho.com>
Cc: Michael Keith <michael.keith(a)oracle.com>; WebBeans
<webbeans-dev(a)lists.jboss.org>; Java Community Process JSR #299 Expert List
<JSR-299-EG(a)jcp.org>
Sent: Friday, January 2, 2009 7:19:20 AM
Subject: Re: [webbeans-dev] Re: Bean.getInjectionPoints()
On Fri, Jan 2, 2009 at 3:42 PM, Gavin King <gavin(a)hibernate.org> wrote:
Actually I think there is a better way to solve the problem, but I
need to talk it over with Pete.
The alternate solution is something like:
interface CreationalContext {
void add(Bean<X> bean, X instance); //registers an "incomplete"
instance
}
interface Contextual<T> {
public abstract T create(CreationalContext ctx);
...
}
interface Context {
public <T> T get(Contextual<T> bean); //get any existing instance
public <T> T get(Contextual<T> bean, CreationalContext ctx);
//get or create an instance
public Class<? extends Annotation> getScopeType();
boolean isActive();
}
interface Manager {
Object getInstanceToInject(CreationalContext ctx,
InjectionPoint ij, Type type, Annotation... bindings);
...
}
And getInstanceToInject() would be smart enough to return any object
that had already been registered with the CreationalContext.
Note that this solution addresses the problem of circular references,
and also fixes a hole in how the Manager knows about the
InjectionPoint.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
3:09 p.m.
New subject: [webbeans-dev] Re: Bean.getInjectionPoints()
@Dependent scoped objects can't all be proxied.
On Fri, Jan 2, 2009 at 5:54 PM, Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com> wrote:
Hi;
Actually the spec requires to return Proxy objects from the
Manager.getInstance(). So the dependency injection does not occur until Bean
method is called, i.o.w Context.get() is not called before the any method
calls on the Bean.
So, circular reference may not be happened with Proxy usage.
Gurkan
________________________________
From: Gavin King <gavin(a)hibernate.org>
To: Scott Ferguson <ferg(a)caucho.com>
Cc: Michael Keith <michael.keith(a)oracle.com>; WebBeans
<webbeans-dev(a)lists.jboss.org>; Java Community Process JSR #299 Expert List
<JSR-299-EG(a)jcp.org>
Sent: Friday, January 2, 2009 6:29:46 AM
Subject: Re: [webbeans-dev] Re: Bean.getInjectionPoints()
On Fri, Jan 2, 2009 at 2:37 PM, Scott Ferguson <ferg(a)caucho.com> wrote:
>
> On Dec 30, 2008, at 1:35 PM, Gavin King wrote:
>
>> The spec requires that injection points be validated at init time for
>> any Bean (for XxxxxDependencyException).
>>
>> Nick from the RI team has noticed that for this to be implementable,
>> we need to add metadata about the injection points of a bean to the
>> Bean interface.
>
> It shouldn't be necessary, since "SimpleBean implements Bean" should
be
> responsible for its own validation. It doesn't make sense for the Manager
> implementation to validate the Bean, since that breaks the encapsulation
> model of both Manager and Bean. It's cleaner for Manager to assume the
> Bean
> is valid.
That only works for Bean implementations provided in the
specification. It does not work for Bean implementations provided by
3rd-party extensions. We need the dependency validation stuff to work
in the second case also.
> On a related note, it would be cleaner if the Bean.create() method was
> changed to Bean.create(Context) in order to handle circular references.
>
> The logic of Bean.create(Context) would be
> 1. check if Bean is in Context (for circular ref), if so return the bean.
> 2. instantiate the Bean (do not inject/initialize) and put it in Context
> (so we have a ref)
> 3. inject/initialize the bean as usual (this may trigger the circular
> reference, which would be resolved by #1 on a second call).
Bean already has a reference to the Manager and can call
Manager.getContext(myScope). So the extra parameter would not be
necessary.
But what you're really saying is that it's better to handle circular
references from Bean.create() than from Manager.getInstance(). OK,
that's really interesting, let me chat to Pete Muir about that and get
back to you.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
3:10 p.m.
New subject: [webbeans-dev] Re: Bean.getInjectionPoints()
No, this stuff does actually require a well-defined contract because
Bean is an extension point that is implemented by third-parties.
On Fri, Jan 2, 2009 at 6:05 PM, Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com> wrote:
Just my comment:
For adding the new API for this complicates the specification.
I think, specification provides the necessary API related with Bean
creation. As I said, these concerns are left to the implementations.
Gurkan
________________________________
From: Gavin King <gavin(a)hibernate.org>
To: Scott Ferguson <ferg(a)caucho.com>
Cc: Michael Keith <michael.keith(a)oracle.com>; WebBeans
<webbeans-dev(a)lists.jboss.org>; Java Community Process JSR #299 Expert List
<JSR-299-EG(a)jcp.org>
Sent: Friday, January 2, 2009 7:19:20 AM
Subject: Re: [webbeans-dev] Re: Bean.getInjectionPoints()
On Fri, Jan 2, 2009 at 3:42 PM, Gavin King <gavin(a)hibernate.org> wrote:
> Actually I think there is a better way to solve the problem, but I
> need to talk it over with Pete.
The alternate solution is something like:
interface CreationalContext {
void add(Bean<X> bean, X instance); //registers an "incomplete"
instance
}
interface Contextual<T> {
public abstract T create(CreationalContext ctx);
...
}
interface Context {
public <T> T get(Contextual<T> bean); //get any existing instance
public <T> T get(Contextual<T> bean, CreationalContext ctx);
//get or create an instance
public Class<? extends Annotation> getScopeType();
boolean isActive();
}
interface Manager {
Object getInstanceToInject(CreationalContext ctx,
InjectionPoint ij, Type type, Annotation... bindings);
...
}
And getInstanceToInject() would be smart enough to return any object
that had already been registered with the CreationalContext.
Note that this solution addresses the problem of circular references,
and also fixes a hole in how the Manager knows about the
InjectionPoint.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
8:53 p.m.
New subject: [webbeans-dev] Re: Bean.getInjectionPoints()
On Jan 2, 2009, at 1:40 AM, Gavin King wrote:
No, this stuff does actually require a well-defined contract because
Bean is an extension point that is implemented by third-parties.
SPI requirements are substantially different from API requirements.
An SPI is basically a driver, and it's appropriate to make validation
demands a driver provider as part of the spec. Writing a Bean will be
rare.
Cluttering up a spec to force validation from an SPI provider is not a
good idea. In general, validation interfaces don't work, and just
make implementations and the spec more difficult and complex, and
don't really save anyone time or improve any quality. Validation
requirements in the written spec are great, of course.
-- Scott
On Fri, Jan 2, 2009 at 6:05 PM, Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com
> wrote:
> Just my comment:
>
> For adding the new API for this complicates the specification.
> I think, specification provides the necessary API related with Bean
> creation. As I said, these concerns are left to the implementations.
>
> Gurkan
>
> ________________________________
> From: Gavin King <gavin(a)hibernate.org>
> To: Scott Ferguson <ferg(a)caucho.com>
> Cc: Michael Keith <michael.keith(a)oracle.com>; WebBeans
> <webbeans-dev(a)lists.jboss.org>; Java Community Process JSR #299
> Expert List
> <JSR-299-EG(a)jcp.org>
> Sent: Friday, January 2, 2009 7:19:20 AM
> Subject: Re: [webbeans-dev] Re: Bean.getInjectionPoints()
>
> On Fri, Jan 2, 2009 at 3:42 PM, Gavin King <gavin(a)hibernate.org>
> wrote:
>
>> Actually I think there is a better way to solve the problem, but I
>> need to talk it over with Pete.
>
> The alternate solution is something like:
>
> interface CreationalContext {
> void add(Bean<X> bean, X instance); //registers an "incomplete"
> instance
> }
>
> interface Contextual<T> {
> public abstract T create(CreationalContext ctx);
> ...
> }
>
> interface Context {
> public <T> T get(Contextual<T> bean); //get any existing
> instance
> public <T> T get(Contextual<T> bean, CreationalContext ctx);
> //get or create an instance
>
> public Class<? extends Annotation> getScopeType();
> boolean isActive();
> }
>
> interface Manager {
> Object getInstanceToInject(CreationalContext ctx,
> InjectionPoint ij, Type type, Annotation... bindings);
> ...
> }
>
> And getInstanceToInject() would be smart enough to return any object
> that had already been registered with the CreationalContext.
>
> Note that this solution addresses the problem of circular references,
> and also fixes a hole in how the Manager knows about the
> InjectionPoint.
>
> --
> Gavin King
> gavin.king(a)gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
>
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
>
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
12:41 a.m.
New subject: [webbeans-dev] Re: Bean.getInjectionPoints()
In the spec says that;
5.4 Client Proxies
* (WebBeans with scope @Dependent never have circular dependencies.)
This means that, developer can not write circular referenced @Dependent beans or RI has to
do something to prevent them?
Thanks;
Gurkan
________________________________
From: Gavin King <gavin(a)hibernate.org>
To: Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com>
Cc: webbeans-dev(a)lists.jboss.org; Scott Ferguson <ferg(a)caucho.com>
Sent: Friday, January 2, 2009 11:39:14 AM
Subject: Re: [webbeans-dev] Re: Bean.getInjectionPoints()
@Dependent scoped objects can't all be proxied.
On Fri, Jan 2, 2009 at 5:54 PM, Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com> wrote:
Hi;
Actually the spec requires to return Proxy objects from the
Manager.getInstance(). So the dependency injection does not occur until Bean
method is called, i.o.w Context.get() is not called before the any method
calls on the Bean.
So, circular reference may not be happened with Proxy usage.
Gurkan
________________________________
From: Gavin King <gavin(a)hibernate.org>
To: Scott Ferguson <ferg(a)caucho.com>
Cc: Michael Keith <michael.keith(a)oracle.com>; WebBeans
<webbeans-dev(a)lists.jboss.org>; Java Community Process JSR #299 Expert List
<JSR-299-EG(a)jcp.org>
Sent: Friday, January 2, 2009 6:29:46 AM
Subject: Re: [webbeans-dev] Re: Bean.getInjectionPoints()
On Fri, Jan 2, 2009 at 2:37 PM, Scott Ferguson <ferg(a)caucho.com> wrote:
>
> On Dec 30, 2008, at 1:35 PM, Gavin King wrote:
>
>> The spec requires that injection points be validated at init time for
>> any Bean (for XxxxxDependencyException).
>>
>> Nick from the RI team has noticed that for this to be implementable,
>> we need to add metadata about the injection points of a bean to the
>> Bean interface.
>
> It shouldn't be necessary, since "SimpleBean implements Bean" should
be
> responsible for its own validation. It doesn't make sense for the Manager
> implementation to validate the Bean, since that breaks the encapsulation
> model of both Manager and Bean. It's cleaner for Manager to assume the
> Bean
> is valid.
That only works for Bean implementations provided in the
specification. It does not work for Bean implementations provided by
3rd-party extensions. We need the dependency validation stuff to work
in the second case also.
> On a related note, it would be cleaner if the Bean.create() method was
> changed to Bean.create(Context) in order to handle circular references.
>
> The logic of Bean.create(Context) would be
> 1. check if Bean is in Context (for circular ref), if so return the bean.
> 2. instantiate the Bean (do not inject/initialize) and put it in Context
> (so we have a ref)
> 3. inject/initialize the bean as usual (this may trigger the circular
> reference, which would be resolved by #1 on a second call).
Bean already has a reference to the Manager and can call
Manager.getContext(myScope). So the extra parameter would not be
necessary.
But what you're really saying is that it's better to handle circular
references from Bean.create() than from Manager.getInstance(). OK,
that's really interesting, let me chat to Pete Muir about that and get
back to you.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
5762
days inactive
5765
days old
13 comments
3 participants
participants (3)
-
Gavin King -
Gurkan Erdogdu -
Scott Ferguson