I'm going through testing the current CDI 3.0.0-RC1 TCK in preparation for
the final release, and there are old integrations like
org.jboss.weld.environment.gwtdev that rely on a jetty-6 release for GWT
stuff. This will not work under the EE9 api change, so I'm going to remove
I'm also trying to update the tomcat and jetty support using the current EE
9 based releases.
We don't have one for undertow yet, so I will disable that for now.
Is there any other cleanup/reorg we want to do as part of this?
I'm using Weld in Open Liberty and seeing a NullPointerException from
WeldInitialListener when an app fails to start. The scenario goes
something like this:
1) Server and app starts to start.
2) An error occurs in my app code throwing an uncaught exception.
3) Liberty's web container code then attempts to stop the
still-not-yet-started app - this calls the WeldInitialListener's
contextDestroyed method without ever calling the contextCreated method.
4) Because contextCreated was never called, there is a NullPointerException
thrown from contextDestroyed (the lifecycle field is null), which ends up
masking the root cause of the problem.
I am in the process of fixing part of the problem (not logging the original
exception) in Open Liberty issue 13124, but I wonder if we should also
check if lifecycle is null in the contextDestroyed method to avoid the
Laird just nominated Graeme as a CDI committer?
---------- Forwarded message ---------
Date: Sun, Jul 19, 2020 at 12:20 PM
Subject: [cdi-dev] Committer Election for Graeme Rocher on Jakarta Contexts
and Dependency Injection has started
To: Jakarta Contexts and Dependency Injection Dev List <cdi-dev(a)eclipse.org>
Cc: ee4j-pmc PMC List <ee4j-pmc(a)eclipse.org>, Eclipse Management
A committer election for Graeme Rocher on project Jakarta Contexts and
Dependency Injection (ee4j.cdi) was started by Laird Nelson with this
I would like to nominate Graeme Rocher for CDI committer status. Graeme is
the creator of several popular Open Source Java-related projects including
Grails and Micronaut and is a Java Champion. Graeme has expertise in AOT
compilation and dependency injection frameworks and has been participating
discussions concerning support for AOT in CDI
experience and knowledge would be a great benefit to the CDI project.
Jakarta Contexts and Dependency Injection project committers can click the
election link below to vote.
cdi-dev mailing list
To unsubscribe from this list, visit
I have recently noticed some Tweets about Helidon running Weld in native. And if memory serves, you are from Helidon team, am I correct?
So first of all, congratulations, CDI in native is no small feat :-)
Seeing that, I went and checked some of the code Helidon is using to work around certain Weld issues you seemed to have encountered.
Things like proxy names but also others such as CL warning in JDK 11, custom weld features and so on...
I know there is bunch of specific things you need to do (such as your WeldFeature class does), but many others are fairly general problems that we would love to have solved in Weld itself.
Which brings me to the question - why not contribute it back to Weld?
You would help an open source project that you are consuming while avoiding the need to substitute our code with bytecode manipulation and hoping we don't change internals to break that.
For instance the aforementioned proxy names problem seems like something we wouldn't mind changing in Weld so that it fits your scenario as it wouldn't break current usage anyway.
Same for class defining in SE for JDK 11+, we even have a tracking issue for that and need a solution much like what you have, only wrapped into a multi release JAR so that it runs on both, 8 and 11+.
And there is probably more, I have only quick-scanned your code and don't know the ins and outs of it.