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
> implementation to validate the Bean, since that breaks the
> 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
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
> On a related note, it would be cleaner if the Bean.create()
> changed to Bean.create(Context) in order to handle circular
> The logic of Bean.create(Context) would be
> 1. check if Bean is in Context (for circular ref), if so return the
> 2. instantiate the Bean (do not inject/initialize) and put it in
> (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
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
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.