Closing all resolved issues in CDI 1.x

Craig, the issue for EntityListener injection is CDI-144

I created CDI-155 for the Instance<T>#destroy() issue to prevent mem leaks with @Dependent beans.

Regarding JPA Entity Listeners, that's going to be fixed in JPA 2.1 ; I got sick of it the issue and nagged the spec team about it. See sections 3.5-3.5.2 in the latest draft (http://java.net/projects/jpa-spec/downloads). Please review it now, don't wait to complain about it once it goes final!

Initial proposal, which deviates totally from what we discussed here at https://github.com/jboss/cdi/pull/43

Issue with all of this is that now destroying this instance is hard. We would need to extend Instance<> with a void destroy(T instance); method.

We cannot split the BeanManager more than in 1.0, but we can add new methods (like the method discussed here) somewhere else.

Mark, you can fire an event when you have an Instance<Object>:

Instance<Object> instance = ...
Event<MyEvent> event = instance.select(new TypeLiteral<Event<MyEvent>>() {}.getType()).get();
event.fire(...);

Since event is a bean, this should work.

Yes as previously commented I was saying simply that if we made it available outside of a managed object it would be via the same mechanisms that we use for all other artifacts from CDI you can look up like this (i.e. currently BM). I'm not in love with the idea that we expose Instance directly, as I think requiring extension authors to write:

Foo foo = beanManager.dynamic().select(Foo.class).get();

(or whatever else this method get's called) is not that onerous given this is extension authors only.

With hindsight I would have preferred to split up BeanManager more than was done in 1.0 but we can't got back and do that now!

But then you hit the scenario that you like to fire an event from a JPA EntityListener (had this recently) and you need the whole BeanManager again

But I'm completely d'accord with you that using the BeanManager or any other SPI outside an Extension should only be a really exceptional case!

It must not be JNDI. We can get the BeanManager from elsewhere (a ThreadLocal or a static singleton from somewhere).

My point was the same as Petes: The BeanManager is for extension developers and they can get it injected, so no need to access it from elsewhere.
Application developers (or users of CDI like Pete called them) should not need to obtain a BeanManager. The only thing they need is to get a contextual reference from within an unmanaged object (like a JPA EntityListener or a Struts Action or other unusual cases). And the ObjectInstance would be great for this. And additionally it provides the "give me all beans of a certain type" access.

Another option would be to provide a SPI to inject into unmanaged instances. Something like BeanManager#inject(Object). But again this needs not to be the BeanManager, because it will be used by application developers and the BeanManager is used by Extension developers.