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>&lt;groupId&gt;javax.enterprise&lt;/groupId&gt;</div>
<div><span class="Apple-tab-span" style="white-space:pre">                        </span>&lt;artifactId&gt;cdi-api&lt;/artifactId&gt;</div><div><span class="Apple-tab-span" style="white-space:pre">                        </span>&lt;version&gt;1.0&lt;/version&gt;</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">&lt;<a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>&gt;</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&#39;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&#39;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 &quot;....parameters are injection points.&quot; We should be<br>
clearer and say &quot;....parameters are injection points of the producer<br>
method bean.&quot;<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&#39;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&#39;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>