[weld-dev] Maintenance release

[Sven Linstaedt]

In Addition to this and to @javax.faces.bean.ManagedBean it seems
there is another @javax.annotation.ManagedBean class that handles
lifecycle callbacks, interceptors and @Resource injection. Do you have
any idea for integrating this one?

br, Sven


2009/12/31, Gavin King <gavin.king at gmail.com>:
> 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
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>