Present ====== Pete Muir Mark Struberg Jozef Hartinger Martin Kouba Jason Porter Joe Bergmark Fabien Marsuad Minor items ========= Mark ran us through https://github.com/jboss/cdi/pull/58 and we agreed with his approaches. These are principally clarifiactions. Mark ran us through https://issues.jboss.org/browse/CDI-247 and we agreed that Martin's proposal of using the default value, as defined by the JLS, could be injected if a a producer returned null for a primitive type wrapper. This is a backwards compatible change, as previously attempting to return null on such a producer resulted in a runtime exception. Action: Pete to review and apply pull requests Multiple Annotated Types ==================== We then moved on to discuss https://issues.jboss.org/browse/CDI-58. This concerns whether there can be greater than one annotated type per class instance in the JVM. Gavin intended there should be, principally to support an XML configuration dialect, which could introduce multiple versions of a class, each with a different qualifier. However, this is not TCK tested, and implementations vary in how they support this. We discussed that this makes an implementation considerably more complex (as there is no easy way to uniquely identify an annotated type e.g. for serialization), and also is pretty confusing for a user (as you now get multiple ProcessAnnotatedType events for each class, making it hard to know which one you want to change). We looked at alternative solutions, and concluded that if all use cases can be satisfied by adding a new bean, rather than a new annotated type, we would like to explicitly specify that there is only one annotated type per class instance. In CDI 1.1 it is already much easier to add and manipulate beans from annotated types, so we believe that the correct thing here is take this route. Action: Pete to contact extension authoring groups, and verify that this approach will work and have minimum impact on existing extensions Visibility of container invoked methods ============================== Currently the CDI specification does not limit the visibility of container invoked methods (observers, producers, initializers). We propose that this should be limited to non-private methods, as otherwise we run into extensive incompatibles with other specs such as EJB, and VMs (such as IBM JDK). Furthermore, having the container invoke private methods deliberately breaks the intended purpose of visibility in Java. Action: Pete to propose change to spec Lack of symmetry between AnnotatedType hierarchy and class hierarchy ======================================================== CDI exposes a flat (merged) annotated type hierarchy whilst Java specifies a hierarchical model. We concluded this doesn't matter, as the identity of all elements on an AnnotatedType is it's signature, which includes the declaring class. In most cases the declaring class is not relevant, the only case in which it is, is injected private fields. We believe the clearly specifying what makes up an AnnotatedType (public methods with overrides resolved, public constructors, all fields) in addition to the addressing the visibility issue will resolve this issue. We need to do this analysis taking into account the inheritance rules specified in CDI and @Inject specs. Action: Pete to draft up proposal