mastertheboss | Source code for mastertheboss.com | Cryptocurrency library

I deployed the ActiveMQ 5.13.13 JCA resource adapter to Wildfly 21.0.1.Final and I didn't see the same logging you saw. Everything appears to be working just fine. Here's what I did:

1. Download & unzip WildFly 21.0.1.Final.
2. Download the ActiveMQ 5.15.13 JCA RA and copy it to standalone/deployments.
3. Added this to standalone/configuration/standalone-full.xml:

When the client creates the session, the broker tries to authenticate the client with the passed username and password.

Your login.config file contains 2 login modules PropertiesLoginModule and GuestLoginModule. If PropertiesLoginModule fails the login because of a wrong username/password the GuestLoginModule will login the user admin with the role amq as defined in your login.config file.

Whenever you use vendor-specific features like RESTEasy dependencies for WildFly, you can't port your application that easily to a different application server (e.g. Payara/Glassfish/Open Liberty).

As a best-practices, just start with the Jakarta EE API dependency:

In ActiveMQ Artemis (i.e. the JMS broker embedded into WildFly) clustering (which provides things like message load balancing) and high-availability (which provides redundancy for the integrity of the message data) are separate concepts. The master/slave configuration you mentioned is for high-availability. This configuration doesn't provide message load balancing since only one of the brokers is alive at any given point in time.

If you want configure a master/slave pair it's recommended that you separate those servers from the servers that actually process the messages since it doesn't make sense to have MDBs running on a server which doesn't have a live broker (i.e. a slave) since they won't receive any messages.

Root url is just a value that will be used for relative paths resolving.

• Root: http://localhost:4200/sign-in
• Valid Redirects: /* (After login user could be redirected to any URI that matches pattern http://localhost:4200/sign-in/*)
• Base URL: / (Is not mandatory. Used when keycloak need to calculate application url by client_id only)
• Admin URL: / (Used when Keycloak need to notify applications about revocation or when user logs out. For example when user logs out in application A if he has session in application B, Keycloak will send backchannel request to Admin URL of application B, so Application B will also flush user session in it)

Check out docs and info badges in Admin Console

A couple things to note:

• To make use of HTTP Basic authentication, an Elytron http-authentication-factory is needed. Documentation on how to configure this can be found here.

• When using HTTP Basic authentication, an application-security-domain mapping also needs to be added in the Undertow subsystem. See https://developer.jboss.org/thread/276445 for more details related to this when using webservices.

This is the final minimal set of commands to configure EJBs access through WS (tested on a clean, brand new Wildfly 14.0.1. Final):

C:\wildfly-14.0.1.Final\bin>jboss-cli.bat
You are disconnected at the moment. Type 'connect' to connect to the server or ' help' for the list of supported commands.
[disconnected /] connect

[standalone@localhost:9990 /] /subsystem=elytron/properties-realm=proxyRealm:add(groups-attribute=groups,groups-properties={path=proxy-roles.properties,relative-to=jboss.server.config.dir},users-properties={path=proxy-users.properties,relative-to=jboss.server.config.dir,plain-text=true})
{"outcome" => "success"}

[standalone@localhost:9990 /] /subsystem=elytron/security-domain=proxySD:add(realms=[{realm=proxyRealm,role-decoder=groups-to-roles}],default-realm=proxyRealm,permission-mapper=default-permission-mapper)
{"outcome" => "success"}

[standalone@localhost:9990 /] /subsystem=elytron/http-authentication-factory=proxy-http-auth:add(http-server-mechanism-factory=global,security-domain=proxySD,mechanism-configurations=[{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name=proxyRealm}]}]
{"outcome" => "success"}

[standalone@localhost:9990 /] /subsystem=undertow/application-security-domain=proxySD:add(http-authentication-factory=proxy-http-auth)
{"outcome" => "success"}

[standalone@localhost:9990 /] /subsystem=elytron/sasl-authentication-factory=proxy-app-sasl-auth:add(mechanism-configurations=[{mechanism-name=JBOSS-LOCAL-USER,realm-mapper=local},{mechanism-name=BASIC,mechanism-realm-configurations=[{realm-name=proxyRealm}]}],sasl-server-factory=configured,security-domain=proxySD)
{"outcome" => "success"}

[standalone@localhost:9990 /] /subsystem=ejb3/application-security-domain=proxySD:add(security-domain=proxySD)
{"outcome" => "success"}

Notes:

1. As you may have noticed, I switched from a FileSystem realm to a Properties realm. This is not related to the issue, it is just that it made easier to debug.

2. Elytron's security domain (defined at the 3rd command), Undertow's application security domain (defined at the 4th command) and EJB's application-security-domain (defined at the 6th command) have all the same name proxySD. That the name is the same in all three subsystems is important, and bad things can happen if they have different names (I have not tried out all the combinations).

3. WS based on EJBs must be invoked with "authenticate pre-emptively", sending the authentication data in the first request without being prompted by the server. WS based on POJOs in a war use the authentication system for web pages, so there is no need to authentica pre-emptively.

That example is quite old, I've created an up-to-date example that I'm planning to inlcude in the project on my personal repository.

Here's the link: https://github.com/DavideD/hibernate-demos/tree/master/hibernate-ogm/nosql-with-hibernate-ogm-101/hibernate-ogm-demo-nosql-with-hibernate-ogm-101-part-3

This project shows how to setup a maven build that prepares WildFly 13 with the appropriate modules using the provisioning plugin. It also show a basic configuration for the persistence.xml and jboss deploy descriptor.

One thing to keep in mind, is that you need to start the server using the proprierty -Dee8.preview.mode=true as you can see in the arquillian.xml

I hope this help

You can use EJBs without dependency injection making a lookup to InitialContext.

After code the Singleton EJB you need to know the "EJB name on JNDI registry" after that you can do:

It's important to note something that's commonly missed; even though the docs for Artemis are not Wildfly-centric, they document the same Artemis you have on Wildfly.

What I'd recommend you do is simple run the following examples. Once you get an idea about the tests, which are explained simplistically in the main class of the examples, then you can easily migrate over the configurations from the generated broker.xml files to your Wildfly configuration.

So, for this shared store example and this replication example do the following:

1. git clone
2. mvn verify
3. Look at the src/main/resources/activemq/server[0-2]
4. Configure your Wildfly with the matching messaging subsystem configuration (you'll see they're almost exactly the same!)
5. Add the true and remove the ${noserver} declaration from the pom.xml and run the main method of the example pointing to your Wildfly server/port to make sure you've gotten your configuration right
6. Then you have a demo using Artemis with Wildfly demonstrating the same capabilities

Have fun and enjoy.