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 <div><span class="Apple-tab-span" style="white-space:pre">                        </span><groupId>javax.enterprise</groupId></div>
<div><span class="Apple-tab-span" style="white-space:pre">                        </span><artifactId>cdi-api</artifactId></div><div><span class="Apple-tab-span" style="white-space:pre">                        </span><version>1.0</version></div>
<div>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.<div><br></div><div>/Johan<br><br><div class="gmail_quote">2009/12/29 Gavin King <span dir="ltr"><<a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Folks, I want to start work on the first CDI maintenance release, and<br>
push it out fairly quickly. We've already discussed a couple of things<br>
that we wanted in CDI 1.0, but had to delay to the maintenance<br>
release:<br>
<br>
* Bean declaration at constructor level<br>
* Abstract producer methods<br>
* Injection into static members<br>
<br>
I want to discuss these things in separate threads.<br>
<br>
I also have a list of enhancements to the portable extension SPI,<br>
which was the least-mature part of the spec, and I would like to<br>
discuss with you guys whether some of those enhancements could/should<br>
be rolled into the maintenance release.<br>
<br>
For now, I just want to update the spec with a list of clarifications<br>
that have cropped up. Please read over these items and speak up if you<br>
have an opinion on any of them!<br>
<br>
++ Methods of abstract decorators<br>
<br>
The CDI 1.0 spec does not define what happens with abstract methods of<br>
an abstract decorator class. This was an oversight. We should probably<br>
say:<br>
<br>
* If a decorator class declares an abstract method that is not<br>
declared by one of the decorated types, a definition error results<br>
* All abstract methods have a container-generated implementation<br>
that simply delegates the method call to the delegate object<br>
<br>
With this definition, I don't think we need any special-casing for<br>
abstract methods annotated @Inject, @PostConstruct, etc.<br>
<br>
++ Clarify that scope types should not have members<br>
<br>
The spec should mention that @ScopeType annotations should not have<br>
annotation members. Perhaps this should be a definition error.<br>
javax.inject.Scope already mentions this.<br>
<br>
++ Clarify that parameters of producer and disposer methods are<br>
injection points of the producer method bean<br>
<br>
We say that "....parameters are injection points." We should be<br>
clearer and say "....parameters are injection points of the producer<br>
method bean."<br>
<br>
++ Clarify that not all classes in a bean archive are bean classes<br>
<br>
We should be clearer and say that you can put non-bean classes (e.g.<br>
MDBs) in a bean archive.<br>
<br>
++ Clarify that there can be multiple AnnotatedType instances per Java class<br>
<br>
This is not 100% clear in the spec.<br>
<br>
++ Clarify that interceptors/decorators don't apply to producers in<br>
resolution rules<br>
<br>
We say this in the preamble, but we should also mention it in the<br>
resolution rules.<br>
<br>
++ In lifecycle chapter, clarify creation of interceptors/decorators<br>
<br>
Not sure precisely what we need to say, but the note in 11.2 is not<br>
sufficient, I think.<br>
<br>
++ Producers and beans that are under construction<br>
<br>
I think we need the spec to say something about cases where an<br>
injection point of a bean resolves to a producer method of the same<br>
bean. The implementation should detect that this is a definition<br>
error. It shouldn't try to call a producer method on a<br>
non-fully-initialized bean.<br>
<font color="#888888"><br>
<br>
--<br>
Gavin King<br>
<a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a><br>
<a href="http://in.relation.to/Bloggers/Gavin" target="_blank">http://in.relation.to/Bloggers/Gavin</a><br>
<a href="http://hibernate.org" target="_blank">http://hibernate.org</a><br>
<a href="http://seamframework.org" target="_blank">http://seamframework.org</a><br>
</font><div><div></div><div class="h5">_______________________________________________<br>
weld-dev mailing list<br>
<a href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br>
</div></div></blockquote></div><br></div></div>