In the next few days we have both the code freeze for GlassFish V3
(Monday 9th November) and the submission of the final draft of JSR-299
(on Wednesday 11th November). We are going to *try* to use the same
release (1.0.0) artifacts for both events (as otherwise I will get
*no* sleep at all ;-). With this in mind, the schedule is as follows:
* Sunday 8th: Code freeze for API project and release CDI API and Weld
- Gavin, this means any changes you want for the 1.0 JavaDoc need
to be in by tomorrow morning. Please tell me if this won't happen.
* Sunday 8th: Code freeze for CDI TCK and release 1.0.0.CR7
- Everyone, please let me know if you have any major outstanding
commits or issues with the TCK asap
- Jozef, I haven't seen any commits for the interceptors spec,
what is your status?
- Shane, please confirm the TCK has been updated to the latest
spec that Gavin has sent out
* Sunday 8th: Code freeze for Weld core, and *hopefully* release 1.0.0
(this is contingent on me not running out of time, otherwise I will
continue on Monday)
- Marius, Roger, can you ping me and we can discuss whether to
slip your remaining issues
- this release will use the 1.0 version of the API and the
1.0.0.CR7 version of the TCK 
* Monday 9th: GlassFish code freeze
* Monday 9th: Ongoing work on TCK and ref docs, and on getting
examples, Servlet, Wicket and SE integration code passing all tests
* Tuesday 10th: Code freeze for example, ref docs, Servlet, Wicket and
SE integration code and release.
* Tuesday 10th: Code freeze and release of TCK 1.0.0
- We will run this against Weld 1.0.0 and verify that we still pass
- Before tagging, we will update the assertions and tests to be
* Tuesday 10th: Build distribution zips for Weld and TCK, QA run
sanity checks, upload to SeamFramework.org
- Ondrej, can you schedule some time for this? Either your Tuesday
afternoon/evening or your Wednesday morning I guess.
* Wednesday 11th: Submit Final Draft of spec, TCK 1.0.0 and Weld 1.0.0
As you can see the schedule is tight, so please ensure you have all
your changes in by the freeze date, or experience my wrath ;-)
Finally, thanks for all your hard work so far!
 Yes, I know this is all upside down, and we should use 1.0.0 of
the TCK in Weld 1.0.0 however it gives us a little more time to add
tests to the TCK, so is worth the weirdness.
In example 1.3.6, method signature has
"public Object authorize(InvocationContext ic) "
AFAIK @AroundInvoke method must obey following signature:
"Object <METHOD>(InvocationContext) throws Exception"
It seems that "throws Exception" part is forgotten!
So I've made some improvements to TypeLiteral and AnnotationLiteral,
including making them serializable.
I need to get some sleep now, but at the last minute I noticed that
AnnotationLiteral is pretty broken for primitive array valued members.
You can't do Object.class.cast() on primitive arrays.
We need to fix that before release.
I have committed code to Weld which breaks the TCK. I need to fix a
few other Weld and TCK issues, and then will do a TCK release.
Sorry about that, if you see failures, feel free to check with me if
they are expected.
I have updated the spec to using the term "bean archive". I also made
a small change to section 9.2 after consultation with Ken and Pete. It
"All interceptors declared using @Interceptor should specify at least
one interceptor binding. If an interceptor declared using @Interceptor
does not declare any interceptor binding, non-portable behavior
Instead of saying that the container must treat it as a definition problem.
I wrote a proposal for creating a Maven Archetype for Weld:
...as well as a JIRA ticket:
The proposal link contains a proof-of-concept/prototype of a Hello World
weld/JSF2 archetype. It would obviously get modified drastically in the
I am hoping that writing a good set of archetypes will greatly help new
users get started with weld.
Pr. Software Engineer
Children's Hospital Informatics Program
Folks, the rules for parameterized types in 5.2.3 are actually not
appropriate for delegate injection points. With an ordinary injection
point, you are instantiating an instance of the bean to inject into
the injection point (so you get to pick the type parameters of the
bean), whereas with a delegate injection point, you are instantiating
a decorator to match the bean (so you get to pick the type parameters
of the injection point).
So I have added in the new section 8.3.1 which lays out the rules for
delegate injection points, and pointed to this in 5.2.
I have also made a slight change to the third bullet point of 5.2.3,
which was unnecessarily restrictive in a corner case.