[cdi-dev] CDI 1.1 EG meeting, 18th Sept

Pete Muir pmuir at redhat.com
Tue Sep 18 04:47:11 EDT 2012


Present
======

Pete Muir
Mark Struberg
Jozef Hartinger
Martin Kouba
Joe Bergmark
Jason Porter
Marius Bogoevici
JJ Snyder

Notes
====

Disabling Extensions
-----------------------------

* CDI-157

Mark and Jason outlined their proposal as described on the issue. Pete to write up.


Application managed contextual instance lifecycle
--------------------------------------------------------------------

* https://issues.jboss.org/browse/CDI-89
* https://issues.jboss.org/browse/CDI-139

Some beans want to manage their own lifecycle, and explicitly destroy an instance.

We discussed adding a destroy() method to an interface which extends Context, which custom contexts need to implement in order to support removing arbitrary instances. This forms an SPI.

We discussed that there should be an SPI for this, and proposed sharing a solution with CDI-139. We ran over all the possibilities we could come up with for identifying the bean to be destroyed, and discussed that either you get passed a dependent scoped instance or a proxy. In both cases, you can destroy the instance from just this info.

Pete to write up.


Proxies or subclassing for interceptors and decorators
-------------------------------------------------------------------------

Discussion on the list :-) 

* CDI-6
* CDI-74
* CDI-44

all relate to this


Superclasses of decorators are decorated types
-----------------------------------------------------------------

* CDI-224

Discussed this, and realised that as the decorated types are a filter for what methods are decorated, allowing decoration of classes would mean that you could no longer use a shared base class for both the decorator and the bean. Also noted that this is not backwards compatible (for the reason just mentioned). Will reject this and see if there is a user outcry!


Alignment of terminology to bean name
-----------------------------------------------------

* CDI-250

EG happy with moving to bean name exclusively


Is ContextNotActiveException thrown when an event is delivered to an observer that is not active?
------------------------------------------------------------------------------------------------------------------------------------

* CDI-75

Mark argued that this isn't 100% clear either way - it's arguable both ways. All agreed that it shouldn't be thrown by default. Will clarify that it isn't thrown, and possibly add a new state in which it is thrown (e.g. Reception.Strict or something somewhat less horribly named ;-)


Require serializable Contextual and CreationalContext
--------------------------------------------------------------------------

* CDI-24

EG happy


Circular dependencies
--------------------------------

* CDI-77

Pete's proposal was to detect cycles at deployment, and error. Mark concerned about performance overhead, and proposed just detecting at runtime. All agreed it would be good to reword the spec to be less ambiguous (currently says "cycles do not occur for dependent beans" which is true, but confusing) and specify what happens when a cycle occurs (StackOverflowException at runtime or deployment error).


Portlet support
--------------------

* CDI-120

EG generally unhappy about adding portlet support at all, and would prefer this to be in another spec. Pete proposed a halfway house, that fits well with what EGs are active - putting the support in a separate document we distribute alongside the CDI spec, like EJB does with interceptors.





More information about the cdi-dev mailing list