[webbeans-dev] Re: Bean.getInjectionPoints()

[Gavin King]

On Fri, Jan 2, 2009 at 4:22 PM, Scott Ferguson <ferg at 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.