12:03 p.m.
Folks, I would like to go ahead and write up this change, unless anyone objects.
It's a hole that needs fixing.
On Fri, Jan 2, 2009 at 4:19 PM, Gavin King <gavin(a)hibernate.org> wrote:
The alternate solution is something like:
interface CreationalContext {
<X> 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
12:35 p.m.
New subject: [webbeans-dev] Re: CreationalContext
On Jan 8, 2009, at 10:03 AM, Gavin King wrote:
Folks, I would like to go ahead and write up this change, unless
anyone objects.
It's a hole that needs fixing.
Is there a need for a separate Contextual<T> or is it essentially
Bean<T>? I mean, it's fine, but I don't understand how the extra
interface helps.
(I'd prefer CreationContext, but that's a very minor preference.)
Also, doesn't InjectionPoint include the <type,bindings> for
getInstanceToInject? How do the extra type, bindings parameters
interact with the InjectionPoint values?
In other words, isn't it sufficient to define the following?
class Manager {
Object getInstanceToInject(CreationContext cxt, InjectionPoint ip)
}
-- Scott
On Fri, Jan 2, 2009 at 4:19 PM, Gavin King <gavin(a)hibernate.org>
wrote:
> The alternate solution is something like:
>
> interface CreationalContext {
> <X> 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
9:02 p.m.
New subject: [webbeans-dev] Re: CreationalContext
On Fri, Jan 9, 2009 at 5:35 AM, Scott Ferguson <ferg(a)caucho.com> wrote:
Is there a need for a separate Contextual<T> or is it
essentially Bean<T>?
I mean, it's fine, but I don't understand how the extra interface helps.
Oh, this was already introduced a few weeks ago. The reason for it was
that frameworks or the container sometimes want to just throw
something in the Context that is not actually a Bean. For example, it
lets the container associate a child manager with an arbitrary
context. It's not related to this proposal.
(I'd prefer CreationContext, but that's a very minor
preference.)
Also, doesn't InjectionPoint include the <type,bindings> for
getInstanceToInject? How do the extra type, bindings parameters interact
with the InjectionPoint values?
Haha, yes, you're right! Silly me :-)
In other words, isn't it sufficient to define the following?
class Manager {
Object getInstanceToInject(CreationContext cxt, InjectionPoint ip)
}
Yes, of course.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
4:49 a.m.
New subject: [webbeans-dev] Re: CreationalContext
Hrm, after further thought I'm not sure this is necessary.
* for objects with normal scope types, you can just inject proxies, no
need to recurse
* dependent objects are unshared, so they don't get added to CreationalContext
So what cases, precisely, were you having problems with, Scott?
I guess I can that it might be useful for pseudo-scopes other than
@Dependent, or possibly as a performance optimization...
On Fri, Jan 9, 2009 at 5:03 AM, Gavin King <gavin(a)hibernate.org> wrote:
Folks, I would like to go ahead and write up this change, unless
anyone objects.
It's a hole that needs fixing.
On Fri, Jan 2, 2009 at 4:19 PM, Gavin King <gavin(a)hibernate.org> wrote:
> The alternate solution is something like:
>
> interface CreationalContext {
> <X> 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
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
9:34 a.m.
New subject: [webbeans-dev] Re: CreationalContext
On Jan 9, 2009, at 2:49 AM, Gavin King wrote:
Hrm, after further thought I'm not sure this is necessary.
* for objects with normal scope types, you can just inject proxies, no
need to recurse
* dependent objects are unshared, so they don't get added to
CreationalContext
So what cases, precisely, were you having problems with, Scott?
Even the most trivial case requires the capability:
@ApplicationScoped
class Foo {
@Current Bar _bar;
}
@ApplicationScoped
class Bar {
@Current Foo _bar;
}
Requiring proxies for all beans is a performance hit which is entirely
unnecessary with the proper SPI.
If the tradeoff is a performance hit on every method call (proxy) for
every bean, vs a slight added complexity in the _SPI_, i.e. an
interface that 98% of developers _never even see_, it should be
obvious that the SPI change is the right one.
I guess I can that it might be useful for pseudo-scopes other than
@Dependent, or possibly as a performance optimization...
It's not an "optimization", it's the basic overhead of the basic
method call.
-- Scott
On Fri, Jan 9, 2009 at 5:03 AM, Gavin King <gavin(a)hibernate.org>
wrote:
> Folks, I would like to go ahead and write up this change, unless
> anyone objects.
>
> It's a hole that needs fixing.
>
> On Fri, Jan 2, 2009 at 4:19 PM, Gavin King <gavin(a)hibernate.org>
> wrote:
>
>> The alternate solution is something like:
>>
>> interface CreationalContext {
>> <X> 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
>
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
7:24 a.m.
New subject: [webbeans-dev] Re: CreationalContext
On Sat, Jan 10, 2009 at 2:34 AM, Scott Ferguson <ferg(a)caucho.com> wrote:
Requiring proxies for all beans is a performance hit which is
entirely
unnecessary with the proper SPI.
If the tradeoff is a performance hit on every method call (proxy) for every
bean, vs a slight added complexity in the _SPI_, i.e. an interface that 98%
of developers _never even see_, it should be obvious that the SPI change is
the right one.
> I guess I can that it might be useful for pseudo-scopes other than
> @Dependent, or possibly as a performance optimization...
It's not an "optimization", it's the basic overhead of the basic
method
call.
OK, but you as the implementer of the Manager and of the most
important implementations of the Bean interface (for simple beans,
producer methods and session beans) can easily provide your own
internal SPI with *your* implementations of Bean, and *your*
implementation of Manager support. Is it *really* important that this
be provided for third-party implementations of Bean?
Really, I'm just asking the question. I'm not against adding this at
all, I'm just trying to balance the additional spec complexity
involved.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
9:11 a.m.
New subject: [webbeans-dev] Re: CreationalContext
On Jan 12, 2009, at 5:24 AM, Gavin King wrote:
On Sat, Jan 10, 2009 at 2:34 AM, Scott Ferguson
<ferg(a)caucho.com>
wrote:
> Requiring proxies for all beans is a performance hit which is
> entirely
> unnecessary with the proper SPI.
>
> If the tradeoff is a performance hit on every method call (proxy)
> for every
> bean, vs a slight added complexity in the _SPI_, i.e. an interface
> that 98%
> of developers _never even see_, it should be obvious that the SPI
> change is
> the right one.
>
>> I guess I can that it might be useful for pseudo-scopes other than
>> @Dependent, or possibly as a performance optimization...
>
> It's not an "optimization", it's the basic overhead of the basic
> method
> call.
OK, but you as the implementer of the Manager and of the most
important implementations of the Bean interface (for simple beans,
producer methods and session beans) can easily provide your own
internal SPI with *your* implementations of Bean, and *your*
implementation of Manager support. Is it *really* important that this
be provided for third-party implementations of Bean?
Well, that's what I'm doing now, but isn't that circumventing the spec?
On the other hand, my major concern was that I'd support circular
references and no one else would, which would be a problem. If
everyone supports the same visible behavior, and I'm not forced to use
a proxy by the spec, (and others use proxies because it's easier to
implement) then I guess it's less important.
Unless the 3rd party Bean implementations become important, and then
they're stuck.
Really, I'm just asking the question. I'm not against adding
this at
all, I'm just trying to balance the additional spec complexity
involved.
Right, but my point before was that different parts of the spec can
handle extra complexity. Anything a normal user sees needs to be as
simple as possible. The SPI can handle some extra complexity, because
the rare Bean developers are more capable.
-- Scott
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
12:04 p.m.
New subject: [webbeans-dev] Re: CreationalContext
On Tue, Jan 13, 2009 at 2:11 AM, Scott Ferguson <ferg(a)caucho.com> wrote:
Well, that's what I'm doing now, but isn't that
circumventing the spec?
Yes, it's a fair point.
OK, I've attached a spec that reworks chapter 5 to add this new approach.
Also see 9.1 and 6.1.
Let me know what you think.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
5:46 p.m.
New subject: [webbeans-dev] Re: CreationalContext
https://jira.jboss.org/jira/browse/WBRI-103
I want to get this into alpha2
On 12 Jan 2009, at 18:04, Gavin King wrote:
On Tue, Jan 13, 2009 at 2:11 AM, Scott Ferguson
<ferg(a)caucho.com>
wrote:
> Well, that's what I'm doing now, but isn't that circumventing the
> spec?
Yes, it's a fair point.
OK, I've attached a spec that reworks chapter 5 to add this new
approach.
Also see 9.1 and 6.1.
Let me know what you think.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
<Web Beans
20090113.pdf>_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
5820
days inactive
5827
days old
8 comments
3 participants
participants (3)
-
Gavin King -
Pete Muir -
Scott Ferguson