Instruct Weld to use a specific classloader instead of hacky solution with thread context classloader

[OndroMih]

GlassFish Version (and build number)

7.0.25

JDK version

N/A

OS

N/A

Database

No response

Problem Description

Because of https://issues.jboss.org/browse/WELD-781, a hacky solution was applied a long time ago (see #18152) to load CDI classes using a specific classloader. So far, no issues with it. However, the Weld issue has been fixed and GlassFish can probably specify the classloader, as suggested by this comment in GlassFish, in

glassfish/appserver/web/weld-integration/src/main/java/org/glassfish/weld/BeanDeploymentArchiveImpl.java

Line 210 in bf590b8

Thread.currentThread().setContextClassLoader(this.moduleClassLoaderForBDA);

:

// The TCL is unset at the end of deployment of CDI beans in WeldDeployer.event
            // XXX: This is a workaround for issue https://issues.jboss.org/browse/WELD-781.
            // Remove this as soon as the SPI comes in.
            Thread.currentThread().setContextClassLoader(this.moduleClassLoaderForBDA);

Steps to reproduce

Currently no issues.

I hit issues when I modified GlassFish code to define a bean deployment archive with a classloader of an OSGi module (for a specific module). Then the thread context classloader was set to this classloader and remained set during the whole Weld deployment, because the method that sets it (getBeanClasses()), is called also in a place where GlassFish doesn't expect that the thread context classloader is modified and doesn't reset it afterwards.

Impact of Issue

Currently no impact. Only cleanup.