[jboss-as7-dev] (JDBC) Driver Registry
Heiko Braun
hbraun at redhat.com
Mon May 9 08:45:37 EDT 2011
Please note that I was talking about the AS7 management API.
Make sure not to mix it with JBDS specific requests and accidentally hijack my thread.
Although the ideas you are describing make sense to me, I still get the feeling it's related
not related to my suggestion at all and does address a different problem domain.
Ike
On May 9, 2011, at 2:37 PM, Joel Tosi wrote:
> Pushing Peter's idea of a central repository slightly further - is this something that we could use in JON? Then standing up new instances would be able to choose from 'available resources' - maybe just defining Schema is it didn't exist?
>
> On 05/09/2011 04:56 AM, Peter Larsen wrote:
>>
>> On 05/09/2011 05:35 AM, Heiko Braun wrote:
>>>
>>> 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.
>>
>>> 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.
>>
>>
>>> 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.
>>
>>> The same mechanism might be used to query available resource adapters or other specific deployment types
>>> that are typically referenced by applications.
>> I think that is a dangerous path. I may have 3-4 database drivers globally in /lib or similar resources that I may not use for project A but I need for Project B. Besides, the driver alone does not give me instance name, host name, user name, password to just mention a few of the required parameters.
>>
>>> 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.
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20110509/a7c3f0c9/attachment.html
More information about the jboss-as7-dev
mailing list