[weld-dev] Maintenance release

[Gavin King]

Yes, unfortunately there are two @ManagedBean annotations in EE6,
neither of which are especially useful when you're using CDI. I
personally argued against having either of them, but my view was not
adopted.

I hope we "prune" the whole javax.faces.bean package out of EE7.

However, note that @javax.annotation.ManagedBean is *already*
integrated with CDI, since we say:

"A top-level Java class is a managed bean if it is defined to be a
managed bean by any other Java EE specification, or if it meets all of
the following conditions..."

On Fri, Jan 1, 2010 at 4:35 AM, Sven Linstaedt
<sven.linstaedt at googlemail.com> wrote:
> 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
>>
>



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