Create data source with CLI in domain mode

[Tim N.]

Hello everybody.

I am trying to deploy JDBC driver and create data source on top of it. Most manuals on the Net recommend to deploy JDBC driver as a module. However, module creation does not work in domain mode. One should manually create them at each server which is pain and break for automated process.

Any way to install JDBC driver and data source on top of it in fully automated way in domain mode? Thank you for guidance.

Best.

[Yeray Borges Santana]

Hello Tim N.,

That's correct, in domain mode, there is no management operation to add a JBoss Modules module. The management operation that adds a module is not prepared to distribute the module across all the remote Host Controllers of your domain.

The way to install automatically a JDBC driver in domain mode is to deploy the driver as a regular application instead of creating a JBoss Modules module on each host instance; the domain controller will distribute it across the server groups you specify when you are deploying the driver. In order to be able to deploy a driver as an application, your driver must be a JDBC4 Compliant driver, check the WildFly documentation about this subject at [1]

Once you have deployed the driver as an application, you have to configure the datasource subsystem on the profile applied to your server groups. You don't need to configure a driver, the driver name will be the name of the driver deployed as an application.

As a quick example (assuming your servers are on 'main-server-group' and this server group uses the profile named 'full'):

[domain@localhost:9990 /] deploy $DRIVER_HOME/postgresql-42.3.2.jar --enabled --server-groups=main-server-group

[domain@localhost:9990 /] /profile=full/subsystem=datasources/data-source=PostgreDS:add(driver-name=postgresql-42.3.2.jar, jndi-name=....., connection-url=.... user-name=....., password=...., ....)

[1] https://docs.wildfly.org/26/Admin_Guide.html#jdbc-driver-installation

Regards,

Yeray

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/5df0a8e8-c908-4045-ae70-47aff52e95d6n%40googlegroups.com.

[Tim N.]

Awesome! Thank you for examples,  Yeray. I will try this out.

One question. While deploying driver can I specify deployment name with "--name" parameter to replace the actual file name with it? If so, should I reference this name in data source instead of driver file name?

Best.

[Yeray Borges Santana]

On Tue, Mar 29, 2022 at 5:32 PM 'Tim N.' via WildFly <wil...@googlegroups.com> wrote:

Awesome! Thank you for examples,  Yeray. I will try this out.

One question. While deploying driver can I specify deployment name with "--name" parameter to replace the actual file name with it? If so, should I reference this name in data source instead of driver file name?

Yes, you can specify the name of your JDBC4 driver deployment by using the "--name" parameter. And, yes, the name of your driver deployment will be the driver name you have to use on your data source configuration.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/e0c8bff5-006a-4254-91f7-3f5f68e8385an%40googlegroups.com.

[Tim N.]

Sorry,  Yeray. Apparently, this is not that simple in some more complex cases. I still have problems with that. See if you can help me. I would appreciate that.

I have tried this approach on existing WildFly server in domain mode that already has some server groups installed and some wars deployed in them. Including their MariaDB JDBC driver!

Strangely, JDBC driver has to be deployed to server group(s). Whereas, data source is defined in profile. It is not clear how data source can work and be dependent on deployed JDBC driver when it is deployed to just some of server groups in this profile but not all of them.

Here is what I tried.

Try #1.

Created new server group for my own purposes. Obviously, it does not have JDBC driver deployed in it yet.
So I deployed my MariaDB JDBC driver to this newly created server group with different name to distinguish it from existing one just in case.

Then I created data source in "full-ha" profile but it complained that the dependency cannot be satisfied for other server groups where I didn't deploy this driver.

Try #2

This time I deployed my  MariaDB JDBC driver to ALL server groups. Again with different name.

I was able to create data source.

However, when I was doing reinstallation and tried to clean up everything I did above I could not remove JDBC driver because, apparently, it became a classpath source for wars installed in these other server groups and now it is locked forever. I could clear it out only after removing all other server groups completely.

---

I will try to recreate above case few more times to make sure I described them correctly. Meanwhile, feel free to request any screen outputs you may think be helpful in resolving this.

Also I really want to understand the concept of JDBC driver and data source working together and be dependent even though they are in completely different hierarchy trees! Driver is in /server-group=codingmanager/deployment and data source is in /profile=full-ha/subsystem=datasources/xa-data-source.

[Yeray Borges Santana]

Hi Tim,

I think the key here is to understand that a server group is used to share a common configuration (a profile) only with the servers included in that server group.

You create common configurations (profiles) and you apply a profile to a server group. All the servers that belong to that server group will get the configuration of the profile applied to that server group. So, you need to have a new profile with the DS configuration and apply that configuration only to the servers you want by using a specific server group.

For your use case, you could:

1. Create a new profile to modify later the data source at your convenience. You can clone a base configuration from an existing profile:

[domain@localhost:9990 /] /profile=full:clone(to-profile=full-for-jdbc-profile)

2. Create a new server group specifying that you want to apply the full-for-jdbc-profile configuration to the servers of that server group. For example:

[domain@localhost:9990 /] /server-group=server-group-for-jdbc:add(profile=full-for-jdbc-profile, socket-binding-group=full-sockets)

3. Assign servers to work under that server group. Stop your Host Controller, edit your host.xml and change the server-group of the servers you want to move to the new server group. For example:

   <servers>
        <server name="server-one" group="server-group-for-jdbc"/>
        <server name="server-two" group="other-server-group">
            <socket-bindings port-offset="150"/>
        </server>
    </servers>

4. Deploy the driver only to the server-group-for-jdbc server group and modify the DS on full-for-jdbc-profile profile:

[domain@localhost:9990 /] deploy $DRIVER_HOME/postgresql-42.3.2.jar --enabled --server-groups=server-group-for-jdbc
[domain@localhost:9990 /] /profile=full-for-jdbc-profile/subsystem=datasources/data-source=PostgreDS:add(driver-name=postgresql-42.3.2.jar, jndi-name=....., connection-url=.... user-name=....., password=...., ....)

You will end up with server-one running on server-group-for-jdbc getting the configuration of full-for-jdbc

The server-two will be running on an independent server-group, other-server-group, using a different DS configuration.

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/9523fe2a-5c67-4f63-869b-8122d437a1cfn%40googlegroups.com.

[Tim N.]

Really great suggestion, Yeray! Thank you. That makes sense. Let me try it out.