[weld-dev] Maintenance release

[Johan Eltes]

This is probably so obvious it hardly needs to be mentioned, but just in
case: it would be great to have the Maven pom for
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
<version>1.0</version>
fixed for the maintenance release. It need to reference the MR of
javax.annotation (jsr-250) so that we get @Resource(lookup and
javax.annotation.sql.

/Johan

2009/12/29 Gavin King <gavin.king at gmail.com>

> Folks, I want to start work on the first CDI maintenance release, and
> push it out fairly quickly. We've already discussed a couple of things
> that we wanted in CDI 1.0, but had to delay to the maintenance
> release:
>
> * Bean declaration at constructor level
> * Abstract producer methods
> * Injection into static members
>
> I want to discuss these things in separate threads.
>
> I also have a list of enhancements to the portable extension SPI,
> which was the least-mature part of the spec, and I would like to
> discuss with you guys whether some of those enhancements could/should
> be rolled into the maintenance release.
>
> For now, I just want to update the spec with a list of clarifications
> that have cropped up. Please read over these items and speak up if you
> have an opinion on any of them!
>
> ++ Methods of abstract decorators
>
> The CDI 1.0 spec does not define what happens with abstract methods of
> an abstract decorator class. This was an oversight. We should probably
> say:
>
>    * If a decorator class declares an abstract method that is not
> declared by one of the decorated types, a definition error results
>    * All abstract methods have a container-generated implementation
> that simply delegates the method call to the delegate object
>
> With this definition, I don't think we need any special-casing for
> abstract methods annotated @Inject, @PostConstruct, etc.
>
> ++  Clarify that scope types should not have members
>
> The spec should mention that @ScopeType annotations should not have
> annotation members. Perhaps this should be a definition error.
> javax.inject.Scope already mentions this.
>
> ++ Clarify that parameters of producer and disposer methods are
> injection points of the producer method bean
>
> We say that "....parameters are injection points." We should be
> clearer and say "....parameters are injection points of the producer
> method bean."
>
> ++ Clarify that not all classes in a bean archive are bean classes
>
> We should be clearer and say that you can put non-bean classes (e.g.
> MDBs) in a bean archive.
>
> ++ Clarify that there can be multiple AnnotatedType instances per Java
> class
>
> This is not 100% clear in the spec.
>
> ++ Clarify that interceptors/decorators don't apply to producers in
> resolution rules
>
> We say this in the preamble, but we should also mention it in the
> resolution rules.
>
> ++ In lifecycle chapter, clarify creation of interceptors/decorators
>
> Not sure precisely what we need to say, but the note in 11.2 is not
> sufficient, I think.
>
> ++ Producers and beans that are under construction
>
> I think we need the spec to say something about cases where an
> injection point of a bean resolves to a producer method of the same
> bean. The implementation should detect that this is a definition
> error. It shouldn't try to call a producer method on a
> non-fully-initialized bean.
>
>
> --
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20100112/4b0afcef/attachment.html