===Previous configuration & situation===

As written https://groups.google.com/forum/#!topic/wildfly/L1BxATschCU,
We were running wildfly 18 and used jwt for securing the application. We did this via a series of cli commands (see server-cli.txt) to configure the server, as well as referencing the created domains in the web.xml.

Under jboss-web.xml we are referencing the "ejb-domain" created in the CLIs. The web.xml (see attachments) protects the resource wit the role referenced in the CLIs (role present in the token)

All our jax-rs resources are annotated with @Stateless and are calling EJBs which in turn are @Statless and declare allowed roles.

===Current situation===
We've upgraded to wildfly 19 in hopes of using microprofile jwt. To do this, we've annotated the Application class with
@LoginConfig(authMethod = "MP-JWT", realmName = "MP-JWT-REALM"), removed the login-config from the web.xml, and removed the security-domain from jboss-web.xml (since otherwise I would receive an error: ELY01148: A SecurityDomain has already been associated with the specified ClassLoader").

After also removing the security-constraint tag from the web.xml I was able to get to the resource and noticed that the JWTToken was properly injected (all claims and entries are there), and the SecurityContext injected in the resource also contained the jwt specific values. From what I can tell, in the context of the jax-rs classloader, I am authenticated.
I would, however, always receive a "Invocation on method... is not allowed" the second the resource would try calling a bean, even if the role matched. Upon checking the logs, and what the injected SessionContext contained, I noticed the principal was anonymous and had no roles allowed.

I therefore believe that the credentials are somehow not being properly passed.

Is there a documented way of properly integrating jax-rs&ejb with microprofile jwt?