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
16 years, 11 months
ref guide (re)draft ready
by Dan Allen
I've made it all the way through the ref guide with revisions that reflect
that changes to the RI and spec names and the latest nomenclature and
semantics from the spec. It's now ready for a technical review and
proofreading (in trunk)
https://svn.jboss.org/repos/weld/doc/trunk/reference
http://anonsvn.jboss.org/repos/weld/doc/trunk/reference
Since there was so much to change, I'm sure there are places where the
semantics didn't get properly updated or an explanation is still out of
date. Also, there were some areas of the ref guide that were thin, and I
didn't have time to fill it all in. If you feel comfortable explaining a
topic, please don't be shy to revise or suggest revisions.
Here are some notes to consider:
- Java SE sections need review for accuracy, relevance
- Extending CDI (extend.xml) is extremely thin, to the point of being
marginally useful compared to the spec
- Weld extensions (extensions.xml) is underwhelming; do we have more to say
than just about logging?
- The chapter on producer fields (producerfields.xml) is missing, though
producer fields are explained in intro.xml
- The Weld SPI needs to be reviewed for accuracy, relevance (ri-spi.xml);
this was a *long* chapter and I just don't know the Weld SPI yet
I did add a lot of content while revising, but the ref guide can always be
improved.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
16 years, 11 months
Weld-logger vs Weld-logging
by Karel Piwko
Hi,
I noticed that there was a module logging in extensions subproject and
it was renamed to logger.
So basically we have artifact with id "weld-logger" but in the
weld-extensions and the documentation we are referencing "weld-logging"
artifact which is not built anymore.
It happens that extensions builds are broken now because of missing
artifact dependency version for "weld-logging" (WELDX-42). I tried to
rename all weld-logging references to "weld-logger" and forced maven to
use dependency version 1.0.0-SNAPSHOT for "weld-logger" and build passed
well.
Please let me know if I got that wrong.
Karel
16 years, 11 months
WeldBootstrap in SE
by Peter Royle
Hi,
Line 128 of WeldBootstrap (core) seems to be causing some Servlet-
specific beans/classes to be registered regardless of the environment
being booted into. The only problem with this is that it breaks in the
SE environment due to the absence of HttpSession (try building the
WebBeans SE extension for example, the test will fail).
I've put in a temporary workaround (just locally) as follows, but this
is just a hack. Anyone close to this code able to offer a permanent
solution?
private final Set<Class<?>> beanClasses =
(Environments.SE.equals(environment))
? Arrays2.<Class<?>>asSet()
: Arrays2.<Class<?>>asSet
(ConversationImpl.class, ServletConversationManager.class,
NumericConversationIdGenerator.class, HttpSessionManager.class);
Cheers,
Pete R
16 years, 11 months
No-snapshots
by Pete Muir
Hi guys,
I've switched us to a "no-snapshots" policy for Weld (both core and
API). This helps improve the reliability of our builds, and makes it
easier to do tagged builds (something Sun need in the run up to the
GlassFish release). Currently this is only enforced manually, but I am
looking at adding enforcing this to the build.
Of course, you will still want to use snapshots locally (likely for
the TCK). To do this, run with, for example: -Dcdi.tck.version=1.0.0-
SNAPSHOT (other useful version properties are weld.api.version and
jboss.interceptor.version).
Pete
16 years, 11 months
Weld Logging
by Peter Royle
Hi,
Has something happened to Weld Logging? It looks to have disappeared.
weld/core/trunk/logging seems to only have a target directory for me
which is weird.
Cheers
16 years, 11 months
