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