Weld 1.0.0 release schedule
by Pete Muir
Hi all,
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
SPI 1.0.
- 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 [1]
* 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
and working
* 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
marked 1.0.FD
* 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
to JCP.
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!
Pete
[1] 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.
11 years, 11 months
Example : 1.3.6 Interceptor Example
by Gurkan Erdogdu
Hi;
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!
Thanks;
--Gurkan
11 years, 11 months
AnnotationLiteral
by Gavin King
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.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
11 years, 11 months
Temporarily expect TCK failures
by Pete Muir
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.
11 years, 11 months
Spec draft and javadoc with "bean archive"
by Gavin King
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
now reads:
"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
results."
Instead of saying that the container must treat it as a definition problem.
Enjoy!
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
11 years, 11 months
Fixed bug in handling of generic types for decorator delegate injection points
by Gavin King
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.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
11 years, 11 months
