"Rewriting original description to clarify things as original was rather franctic on my part.  This goes through two iterations showing issue we faced with 3.1.7.Final and finally the issue of real concern here with 3.1.7.SP1.  This is hopefully helpful to others that might have similar issue and may be able to chime in."

Our application stack uses full Java EE (CDI/Jersey/Metro/Faces) with spring boot using Joinfaces to allow integration between the two frameworks and some custom bindings for Java Metro Injections.  This is ran in jdk 11 environment currently with embedded tomcat and many specific libraries exploded for the JAR content so they can work with spring boot needs.  With Weld 3.1.6.Final, all works incredibly well.  We have been on spring boot this way for roughly 2 years and have been using Weld since 2010 in the same products.

We have two primary stacks.  One additionally contains mybatis-cdi with mybatis for database activities using mybatis.  We initially detected upgrade to Weld 3.1.7.Final failed to startup on the application with mybatis-cdi with this upgrade.  We subsequently saw the patches already commited but not released and assumed correctly it would be fixed shortly.  We did not try to upgrade elsewhere at that time.

I work on the mybatis-cdi module on github and was able to confirm situation there as well.  The good news here is that Weld 3.1.7.SP1 has resolved the issue with mybatis-cdi both on our stack as well as the github repo and the repo is now applied with Weld 3.1.7.SP1 as a result this morning.

For reference this was done here https://github.com/mybatis/cdi/pull/211.

Both our applications are using Deltaspike framework.  I will work on getting a stack trace as our code is not public.  Therefore the remainder of this is just a general description of what we are seeing.  The problem exibits itself in Deltaspike DefaultMessageContext during startup and applicaton then fails to start with Weld 3.1.7.SP1.  It is similar to other reported issues thus far on Weld 3.1.7.SP1 that I've seen but our use case is different.

The error message seen states "Unable to load proxy for managed bean for Deltaspike Default Mesage Context."  We are using latest on all libraries (before Jakarta EE package renames of course).  When this error presents itself, other JSF related integration starts to throw exceptions as well.  Omnifaces specifically throws a banner that CDI is not available in the container.  That is a side effect of Weld failing by this point.  There is at least one class not found showing up that is from Deltaspike but the class is there and most likely due to the proxy issue.  We are not able to go back to running on java 8 here as we use java features introduced since java 10.

Original message

"As with 3.1.7.Final over 3.1.6.Final, running in jdk 11 enviornment, code stopped working for many products.  With 3.1.7.SP1, now also getting failure.  Unable to load proxy for managed bean for Deltaspike Default Mesage Context.  Using deltaspike 1.9.5 (latest).  Only update was to move from weld 3.1.6.Final to 3.1.7.SP1.  This causes cascading issue with all jsf components then starting to fail with null pointers and omnifaces reporting that cdi doesn't exist in this environment.  Our implementation is running in spring boot with joinfaces as well.  No issues here until the proxy changes starting in 3.1.7.Final.  I need to recheck 3.1.7.Final to see if error was different but suspect it was as we found issues with mybatis-cdi on a  separate project.  Any ideas on what migth be causing issue?  Obsolutely no changes except 3.1.7.Final or 3.1.7.SP1.  I do see as others have with class not found issues too in this case around deltaspike so I think its similar to earlier reported issues on 3.1.7.SP1."