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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev