Hi, We have integrated Artemis 1.x in WildFly application server with a different SQLProvider implementation to support Artemis JDBC store. The issue we had at the time with Artemis SQLProvider was that supporting a new databases required to add a new class to specify its specific JDBC statements and ultimately require new releases for each new DB we wanted to test & support.
To circumvent this issue, we wrote a SQLProvider[1] to use for Artemis JDBC store that is using a Properties file[2] and a simple overridding mechanism to provide DB-specific statements. For example to support Oracle DB, Artemis mechanism required to write (and maintain) this class: https://github.com/apache/activemq-artemis/blob/master/artemis-jdbc-store/src/main/java/org/apache/activemq/artemis/jdbc/store/drivers/oracle/Oracle12CSQLProvider.java Using our property-based implementation, we only need to add 2 lines to the properties file: https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/messaging-activemq/main/database/journal-sql.properties#L43-L45 When the SQLProvider will be queried for a SQL statement, it will first searched for a DB-specific dialect and falls back to a generic one else: https://github.com/wildfly/wildfly/blob/master/messaging-activemq/src/main/java/org/wildfly/extension/messaging/activemq/PropertySQLProviderFactory.java#L249 The dialect itself is determined used DataSource properties and metadata: https://github.com/wildfly/wildfly/blob/master/messaging-activemq/src/main/java/org/wildfly/extension/messaging/activemq/PropertySQLProviderFactory.java#L85 In addition, this properties file can be easily modified by users without requiring a new release to support another database. We have started development on WildFly 12 and I am looking to integrate Artemis 2.4.x. I don't want to have to maintain a 2nd implementation of the SQL provider in WildFly codebase and I really think that our properties-based approach is sounder than the current Artemis implementation. I'd like to propose to contribute back this properties-based SQL provider to Artemis codebase in replacement to its current implementation. I think this would be beneficial for Artemis as it would reduce the amount of work to support a new DB, reduce the number of classes for a better maintainability and, of course, ease the integration of Artemis into WildFly. What do you think? jeff [1] https://github.com/wildfly/wildfly/blob/master/messaging-activemq/src/main/java/org/wildfly/extension/messaging/activemq/PropertySQLProviderFactory.java [2] https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/messaging-activemq/main/database/journal-sql.properties -- Jeff Mesnil jmes...@gmail.com http://jmesnil.net/weblog/
