[weld-dev] Maintenance release

[Gavin King]

Here's something else that has come up:

http://smokeandice.blogspot.com/2009/12/datasourcedefinition-hidden-gem-from.html

Basically, the common annotations spec introduced the
@DataSourceDefinition annotation without telling anybody about it, so
as usual we have new bits of the platform which don't work properly
together. Grrr.

We should say that if this annotation is used on a class annotated
@Alternative, then it is only activated if the alternative is enabled.

On Tue, Dec 29, 2009 at 4:44 PM, Gavin King <gavin.king at gmail.com> wrote:
> 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
>



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org