[weld-dev] Maintenance release

Pete Muir pmuir at redhat.com
Wed Jan 13 08:29:59 EST 2010


Johan, 

Can you make sure there is a WELD issue filed for this?

We need to do some other small fixes to the API jar such as javadoc changes anyway, so there will be a service release of the API jar in Maven before the MR I think.


On 12 Jan 2010, at 21:11, Johan Eltes wrote:

> 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
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev




More information about the weld-dev mailing list