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.

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.

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.

The same mechanism might be used to query available resource adapters or other specific deployment types that are typically referenced by applications.

Any reasons why this cannot be done? Any objections why it shouldn't be? Other ideas how this situation can be improved?

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

From: "Heiko Braun" <hbraun(a)redhat.com&gt; To: &quot;jboss-as7-dev(a)lists.jboss.org Development" <jboss-as7-dev(a)lists.jboss.org&gt; Sent: Monday, May 9, 2011 3:35:59 AM Subject: [jboss-as7-dev] (JDBC) Driver Registry 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. 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. 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. The same mechanism might be used to query available resource adapters or other specific deployment types that are typically referenced by applications. Any reasons why this cannot be done? Any objections why it shouldn't be? Other ideas how this situation can be improved?

Ike _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On May 9, 2011, at 4:49 PM, Andrig Miller wrote: > > One problem we have is distribution of the drivers. For the open source drivers, its not a problem, but for close source drivers I don't believe their licenses allow us to distribute them, so that could be one impediment to doing this, as I assume that we would need to distribute the drivers within the registry. > > I really like this idea in general, but it may be limited in usefulness if we cannot do it for close source data sources. > > Do you think we could attempt to grab the strings right from the jar file MANIFEST.MF, and the META-INF/services? In looking at the MySQL and PostgreSQL drivers I have installed, it would work for MySQL, but not for PostgreSQL. Not sure about other drivers. The PostgreSQL driver jar files MANIFEST.MF file doesn't contain the version information like MySQL does, but perhaps if the closed source drivers have such information, we could get the Postgres guys to add it. > > Andy I do not necessarily mean that we need to distribute the driver binaries, although that came to my mind as well. What I mean is a registry for drivers that are (manually) deployed or registered as modules. However that enter the domain I would need to be able to query the domain API to retrieve a list of available drivers including the driver class, name and version. Ike _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

If I understand the request properly, you're looking for something like what I did for AS7-328, but that applies to the domain model. The AS7-328 thing only provides information at the server level, so it's not very helpful for domain mode. For drivers that are installed as modules, the datasource subsystem <drivers> element provides a registry. The issue is drivers installed via deployments. We don't know that a deployment is a driver until the deployment processors in the servers get hold of it. The DC has no notion of a deployment processor; to it a deployment is just a bunch of bytes with a name attached. Some brainstorming solutions: 1) Drivers become a first class citizen in the domain model, peers to deployments. They then need to be mapped to server groups. Packaging them in other deployments is verboten, since then a single piece of content would be represented by two different pieces of the model. 2) We add some deployment unit processing to the domain controller. This is something we'd talked about in the past. So stuff I'll be working on with David this week could lay the foundation for that. I'm not too keen on trying to shove the actual feature into 7.0. though. Note that even with this registry, tools or the humans using the tools will need to do some manipulation to figure out a valid list of drivers. Profiles and deployments are independent things; if you add a datasource to a profile, whether that datasource will work on the servers depends on whether the driver deployment is mapped to all the server groups that run the profile. Re: the distribution issue, if a user uploads a driver jar to the domain as deployment content, we're going to distribute it. Well, we're not going to distribute it; the user is going to distribute it using our software. I don't see why that would be a problem though. [1] https://issues.jboss.org/browse/AS7-328 On 5/9/11 9:53 AM, Heiko Braun wrote: > > On May 9, 2011, at 4:49 PM, Andrig Miller wrote: > >> >> One problem we have is distribution of the drivers. For the open source drivers, its not a problem, but for close source drivers I don't believe their licenses allow us to distribute them, so that could be one impediment to doing this, as I assume that we would need to distribute the drivers within the registry. >> >> I really like this idea in general, but it may be limited in usefulness if we cannot do it for close source data sources. >> >> Do you think we could attempt to grab the strings right from the jar file MANIFEST.MF, and the META-INF/services? In looking at the MySQL and PostgreSQL drivers I have installed, it would work for MySQL, but not for PostgreSQL. Not sure about other drivers. The PostgreSQL driver jar files MANIFEST.MF file doesn't contain the version information like MySQL does, but perhaps if the closed source drivers have such information, we could get the Postgres guys to add it. >> >> Andy > > > > I do not necessarily mean that we need to distribute the driver binaries, > although that came to my mind as well. > > What I mean is a registry for drivers that are (manually) deployed or registered as modules. > However that enter the domain I would need to be able to query the domain API to retrieve a list > of available drivers including the driver class, name and version. > > > Ike > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

1) Drivers become a first class citizen in the domain model, peers to deployments. They then need to be mapped to server groups. Packaging them in other deployments is verboten, since then a single piece of content would be represented by two different pieces of the model. 2) We add some deployment unit processing to the domain controller. This is something we'd talked about in the past. So stuff I'll be working on with David this week could lay the foundation for that. I'm not too keen on trying to shove the actual feature into 7.0. though.

Yeah there's absolutely nothing stopping us from recognizing JDBC driver types and knowing what defaults make sense for them, and how to work around their various problems; I think this would add a lot of value. Querying the domain for JDBC drivers doesn't really make a lot of sense IMO. You could support querying the domain for drivers configured via profiles, I suppose, but again that really makes sense at the profile level only. Querying for deployed driver types doesn't seem too useful to me either. I think that it's more important in this case to reflect the model as it really is and not try to create the illusion of some representation that isn't even possible.

On May 9, 2011, at 5:40 PM, David M. Lloyd wrote: > Yeah there's absolutely nothing stopping us from recognizing JDBC driver > types and knowing what defaults make sense for them, and how to work > around their various problems; I think this would add a lot of value. > > Querying the domain for JDBC drivers doesn't really make a lot of sense > IMO. You could support querying the domain for drivers configured via > profiles, I suppose, but again that really makes sense at the profile > level only. Querying for deployed driver types doesn't seem too useful > to me either. I think that it's more important in this case to reflect > the model as it really is and not try to create the illusion of some > representation that isn't even possible. Not sure if I understand the second half correctly: "Querying the domain for JDBC drivers doesn't make sense" The use case is as follows: 1) Specify datasource name, jndi 2) select driver 3) provide remaining config attributes 4) done This will create a domain level datasource configuration. The second step is the one that's causing the trouble atm. Hence the question if it would be possible to query the available drivers. Why doesn't it make sense?

On Monday, May 09, 2011 11:58:38 AM David M. Lloyd wrote: > Because drivers don't always exist at the same level as datasources. > You can choose from a list of profile-defined drivers, sure, but you > cannot select from deployed drivers. It just won't work, unless you add > a "query server for deployed drivers" option or something. which is what we are adding an operation for such that Ike can build a drop- down of available drivers.

Best regards, Jesper _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I brought up this issue again, because it never came to a satisfying solution. But speaking to David and Brian again I believe we have to leverage AS7-328 for the time being. Even if it has several drawbacks: - request for each server - unassigned drivers (exist in repo, but are not "deployed") will not show up

- unassigned drivers (exist in repo, but are not "deployed") will not show up

Hi Brian, I've take a look to the issue and to your patch. In fact it's more or less what I was going to implement too. If you agree I can take this issue, merge your stuffs and changes I'm doing for AS7-711 and provide a single patch with reviewed jdbc driver use and registry.

We can discuss about that in IRC later of course...I have enough issue on my plate for this mornin, I can wait for this one :) regards S. On 05/09/2011 06:07 PM, Brian Stansberry wrote: > On 5/9/11 11:01 AM, Jesper Pedersen wrote: >> On Monday, May 09, 2011 11:58:38 AM David M. Lloyd wrote: >>> Because drivers don't always exist at the same level as datasources. >>> You can choose from a list of profile-defined drivers, sure, but you >>> cannot select from deployed drivers. It just won't work, unless you add >>> a "query server for deployed drivers" option or something. >> which is what we are adding an operation for such that Ike can build >> a drop- >> down of available drivers. >> > That's already there at the server level; see > https://issues.jboss.org/browse/AS7-328 > >> Best regards, >> Jesper >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >