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)
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
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
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
Please let me know if I got that wrong.
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
private final Set<Class<?>> beanClasses =
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