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

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