wildfly + pgjdbc-ng

[bartkaptur]

Hi. I've tried to deploy a datasource to wildfly 17.0.1 by putting an xml file in /standalone/deployments. The user guide says this should work:

<connection-url>jdbc:pgsql://my.server.com:5432/my_database</connection-url>

It didn't - it tried to connect to localhost, as if this data never got to the pgjdbc driver. I changed it to:

<connection-property name="databaseUrl">jdbc:pgsql://my.server.com:5432/my_database</connection-property>

...and it works just fine. Please let me know, if it is the proper way to do it, or if the first one should work, but there is a bug of some kind.

[kdubb]

From the user guide (note the version reference):

These instructions were created using WildFly 15.0.1.Final as a reference. Earlier or later versions of WildFly may use slightly different commands, terminology and/or layouts, although the steps for deployment remain similar.

I've not attempted to work with Wildly 17.0.1 or verify the user-guide's instructions against it but it appears you have 😉. If that's working then I would say you are correct.

User-guide Update

If the format has changed, I am happy to update the documentation with this difference. In support of that, can you find any Wildfly documentation that suggests this change to the xml between 15 & 17 to help me narrow down what exactly has changed?

Also, PRs are welcome. Updating the documentation is very easy and would be a great contribution.

[bartkaptur]

Hi again. Thank you for the answer. I've tried to do this thing on Wildfly 15.0.1.Final - the result I'm getting is exactly the same.

The scenario for a running wildfly with a datasource configured in an xml file in standalone/deployments (database address provided with connection-url), and a web service provided by a jar in the same location: -I call the web service - it works. -I then force postgresql to close the connection made by wildfly (select * from pg_stat_activity, and then select pg_terminate_backend (PID)) -I call the web service again - i get "Unable to get managed connection for ...".

The second web service call works fine when I provide the address in a connection-property tag - wildfly recreates the connection. It also does so when I re-reploy the datasource xml. I've tried to dump some information from the pgjdbc-ng code and all I'm getting is that, when using connection-url, the host address passed into pgjdbc is a null, even though other things like username and password come through properly. It may be a wildlfy bug, or something with my server config. Please check if you can recreate the scenario - then at least I'll know which one it is.

Another possible problem to be fixed inside pgjdbc-ng: when it receives a null host, it defaults to "localhost:5432". My database actually can be accessed like this (which made the problem harder to spot - it took some time to notice that my connection-url seems to be ignored) and pgjdbc creates the connection all right, but then fails at re-creating it, because only then it tries to parse the address using the big regexp which demands a non-empty database substring. Just putting it out there: why have a default host at all?

[kdubb]

@bartkaptur Thanks for all these additional details. This gives me some concrete scenarios to investigate. I will try some things on my end and report back.

WRT the default host, connecting via Datasource users are allowed to provide individual properties and when using that method it assumes a defaults for most all of the properties except for (some of that is dictated by JDBC).

Edit: (the URL regex was change significantly in 0.8.x)

The URL regular expression actually doesn't require any hosts at all urls of the form jdbcpgsql:database are allowed. The only difference between the URL defaults and the DataSource defaults is that the url requires a database name and the DataSource defaults to the login user name. We could go further and allow no database name in the URL (e.g. jdbc:pgsql:) to ensure both methods have the same defaults.