I've seen that as part of the ESB configuration, multiple compile-time options are available to either work on a PostgresSQL or HSQLDB database. While this is all fine if you are about to build your own ESB from the source, it might be benefitial to offer options for the pre-packaged ESB.
By default, I imagine we are going to provide a pre-packaged ESB working on a minimal MK (or MC in the future) that doesn't required any further configuration (much like the AS). To that end, the only real possibility is to offer an HSQLDB default setup with additional optional configuration files available for other DB.
Optional configuration files are usually found in the JBOSS_HOME/docs folder for the AS, the same could be done for the ESB.
For the base behaviour we could either i) provide the ESB with a preconfigured ESB or ii) setup a mechanism to setup the DB at runtime.
I am not a fan of i) as DB files (especially HSQLDB) might get dirty and then the users will not be able to fix that issue easily (excpet if you are able to read proprietary binary formats on the fly and write them as well).
For option ii), one easy option is to keep providing the Beanshell deployer currently available in JBoss AS (or any other script deployer) and provide a setup-esb.bsh script that would perform all necessary duties. For example:
- test that no ESB table exist yet.
- if that is the case, create the table
- populate it with basic/example data
None of these checks (or any additional setup steps) are necessarily trivial when simply relying on a SQL script (useless at runtime btw), but are really trivial when running them from a beanshell script that can rely on JDBC, JNDI, the ESB itself, JVM options, OS information, etc.
Some sample scripts are available as part of the AS and, at least in the past, available for the Portal setup that uses such scripts so setup its default DB environment as well.
We definitely should support a DB setup out of the box, that does not require any changes to the configuration data. Obviously we'd need to make some assumptions, but if that improves the initial out-of-the-box configuration then that's good.
The RC support hsqldb out of the box (using option i). However I'm not using the beanshell deployer. It would be nice to use that for GA. Where can I find that code in JBossAS?
I notice that the jbossesb-properties file has a dbstore properties that specifies jdbc connection properties. Can / should that file allow a datasource to be specified as an alternative?
What is the JBossESBDS datasource used for?
It currently does not support a j2ee datasource, that is planned for post-GA. There are known issues with the connection pooling (3cpo) and hooking it up to use a datasource. The direction taken when writing the message store was to work as a totally standalone message persistence mechanism. Now that we have started packaging SARs I need to revisit this so that we can in fact hook into a datasource. It is possible, but I know it has problems. Since we can't introduce any code changes that would potentially break anything, I have held off on this till after the G.A.
Can't we use the pooling from JBossAS in that case? Anyway that is why I already created a hsqldb datasource for it.