Cleaning up weld core master
by Scott Stark
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
it.
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?
3 years, 8 months
NullPointer in WeldInitialListener
by Andy McCright
Hi All,
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[1], but I wonder if we should also
check if lifecycle is null in the contextDestroyed method[2] to avoid the
NPE.
Thanks,
Andy
[1] https://github.com/OpenLiberty/open-liberty/issues/13124
[2]
https://github.com/weld/core/blob/2fe5d1f64c03b89cc562a14cda317098225590c...
3 years, 9 months
Helidon and Weld in native
by Matej Novotny
Hi Laird,
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[1] 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[2] 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[3] 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.
Best regards
Matej
__________________________________________________________________________________________________________
[1] https://github.com/oracle/helidon/blob/master/integrations/graal/mp-nativ...
[2] https://github.com/oracle/helidon/blob/master/integrations/graal/mp-nativ...
[3] https://issues.redhat.com/browse/WELD-2619
3 years, 9 months
