Security API deployment failure in Payara Full CE 5.2022.1

In my EAR is a WAR that contains a custom security extension:

@ApplicationScoped
public class CustomAuth implements HttpAuthenticationMechanism {

    @Override
    public AuthenticationStatus validateRequest(HttpServletRequest request, HttpServletResponse response, HttpMessageContext httpMsgContext)
            throws AuthenticationException {
        return httpMsgContext.responseUnauthorized();
    }

}

When performing BASIC Auth’ed request, the following is shown in the server.log:

[2022-03-23T09:34:02.976+0100] [Payara 5.2022.1] [WARNUNG] [] [javax.enterprise.system.container.web.com.sun.web.security] [tid: _ThreadID=78 _ThreadName=http-thread-pool::http-listener-1(1)] [timeMillis: 1648024442976] [levelValue: 900] [[
JASPIC: http msg authentication fail
org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001334: Unsatisfied dependencies for type HttpAuthenticationMechanism with qualifiers
at org.jboss.weld.bean.builtin.InstanceImpl.checkBeanResolved(InstanceImpl.java:241)
at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:113)
at org.glassfish.soteria.mechanisms.jaspic.HttpBridgeServerAuthModule.validateRequest(HttpBridgeServerAuthModule.java:149)
at org.glassfish.soteria.mechanisms.jaspic.DefaultServerAuthContext.validateRequest(DefaultServerAuthContext.java:76)
at com.sun.web.security.realmadapter.JaspicRealm.validateRequest(JaspicRealm.java:391)
at com.sun.web.security.realmadapter.JaspicRealm.validateRequest(JaspicRealm.java:358)
at com.sun.web.security.realmadapter.JaspicRealm.validateRequest(JaspicRealm.java:181)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:487)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:468)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:726)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:581)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:158)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:371)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:520)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:217)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:182)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:156)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:218)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:95)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:260)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:177)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:109)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:88)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:53)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:524)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:89)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:94)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:33)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:114)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:569)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:549)
at java.base/java.lang.Thread.run(Unknown Source)
]]

Apparently the message is nonsense, as this custom code does neither have any qualifiers nor dependencies declared.

Now comes the funny thing. I redeploy the unchanged EAR once more, and the extension works as intended!

This happens each time I build my EAR. It seems that the deployment of Security API inside EAR is somehow unreliable.