[jboss-as7-dev] (JDBC) Driver Registry

[Max Rydahl Andersen]

>> Following up with some of the discussion we'd been having in the past few weeks,
>> I would like to call for comments on the idea of a central, domain level driver registry
>> that can be used to query specific deployments like JDBC drivers.
> 
> What I am missing is a registry/wizard help in JBDS to setup data sources easily. Something where I can quickly create a data source, and test it, from within JBDS, but where I can also bring up the wizard and add more advanced options.

JBDS does not currently plan to "compete" against the console for setting up datasources.

What we do want to do though is being able to define a datasource in a text file (i.e. ds.xml or application.xml) and deploy that side by side 
with the application (i.e. not inside it). 

If we do anything it would be to define the bare minimum settings for a datasource and then if the user needs more advanced tuning he uses
the console. 

Thus a great feature would be to be able to "copy a non-managed datasource" to a "real managed datasource" to allow further tweaking.

>> Creating datasource configuration is currently way to complex for the average user.
>> Once you've deployed the JDBC driver you need provide the correct driver name, driver class and version
>> besides the regular data source attributes. Since we are lacking a way to query for installed JDBC drivers
>> this currently means providing the required attributes as string values.
> Currently we have partly a wizard driven method of doing this for Hibernate but it somehow doesn't relate to the persistence.xml which SEAM works on. I also find that I usually work from the usual 5-10 different data sources over multiple projects. Creating a repository or registry where I can define my data-sources _once_ and simply pull them in to my current project would be helpful.  Maybe somekind of "data-sources.xml" can be used to store the registry, imported and exported to/from workspaces would allow the developer to quickly get common configurations going for a new workspace/project.
> 
> There's another advantage - if a password changes to a data-source, just changing the registry should be enough to change all deployed versions of that data-source.

You seem to be mixing runtime and dev time concerns here. Using persistence.xml from tooling (any tooling actually) does not make sense since
datasources are not available without a server.

Having a "shared" form of datasource configurations makes perfect sense though. that is why we use the DTP tools in JBDS to read our connection info from.

I've had a long standing issue open about reading datasource info from -ds.xml files and expose those in DTP; we could look into doing the
same for AS 7 datasources assuming we can get all the needed details (username/password/driver.jar/driverclass) from it.

>> A more simple and less error prone approach would be to provide a selection of drivers to chose from.
>> But this would require something like a domain level driver registry.
> That's already in JBDS? It's a bit buggy since it cannot locate the driver JAR files correctly but it's there. It would be nice if selecting a database type would automatically install/implement the correct driver.

Not possible for license reasons. Only h2, hsqld or postgres would work here. Even Mysql have problems here.

> 
>> Any reasons why this cannot be done?
>> Any objections why it shouldn't be?
>> Other ideas how this situation can be improved?
> A central repository for pre-configured data-sources that includes not only the driver, but url, username, password and hopefully room for some of the advanced parameters too would be helpful.  Doing it outside JBDS makes little sense to me. And there needs to be a "reconcile" option so changes done to the registry can be adopted to the project/application.

Peter, I don't understand why you want a central repo for datasources but then say you want it inside JBDS....then it is no longer central nor can be used by anything but JBDS.

/max