Re: [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.