Bug 328310

Comment 1 Sander 2010-10-21 01:27:58 EDT

It seems PostgreSQL has multiple libraries for different versions of the JDBC driver. However when I downloaded version 9.0-801 for JDBC 4 the build file suggested otherwise. The Derby driver supports JDBC 3 and JDBC 4, I think it would be best to continue this strategy. However, my question would be: what PostgreSQL versions will be supported? Personally I only need 9.0 but I guess most organizations are still using 8.4.

Comment 2 Sander 2010-10-21 03:18:58 EDT

Created attachment 181361 [details]
Initial proposal version

Version based on some basic functionality of the Derby driver. It's actually an extension of the PostgreSQL driver (9.0.801) itself since it relies on the build file to determine which JDBC version to use.

This version is loosely tested in a proprietary project with Apache Felix, Gemini and Eclipselink.

If this is accepted as initial version we should consider committing the code to the repository of PostgreSQL (as a branch) instead of to the dbaccess project.

Comment 3 Michael Keith 2010-10-21 11:24:55 EDT

It should be possible to implement most of it in a way that is version agnostic, as long as they haven't changed the names of their driver classes. If they have, then the implementation could be adaptive to the classes, but in the end I think it makes the most sense to implement it as a layer above the driver, not in the actual PostgreSQL project.  My experience with such established large projects is that it is hard to get them onto new technologies. On the other hand, if you can get the project committers to buy into being more modular and also provide these services in each release from now on then it would be worth it.

Comment 4 Sander 2010-10-21 19:04:13 EDT

(In reply to comment #3)
> It should be possible to implement most of it in a way that is version
> agnostic, as long as they haven't changed the names of their driver classes. If
> they have, then the implementation could be adaptive to the classes, but in the
> end I think it makes the most sense to implement it as a layer above the
> driver, not in the actual PostgreSQL project.  My experience with such
> established large projects is that it is hard to get them onto new
> technologies. On the other hand, if you can get the project committers to buy
> into being more modular and also provide these services in each release from
> now on then it would be worth it.

I totally agree. However, I find it a little strange to create a separate bundle for only the OSGi-JDBC support, especially since we have to change the PostgreSQL driver since it doesn't even provide a manifest file supporting OSGi. What is the motivation to create two separate bundles for this?

I'd like to know what you think of proposal version uploaded as attachment.

Comment 5 Michael Keith 2010-10-25 14:19:45 EDT

Hi Sander,

One way is to wrap the Postgres jars with some code of your own and export what needs to be exported. That allows you to not have to mix in your code with the postgres classes (written as part of the {Postgres project). That is the primary way that I would expect to write dbaccess jars for non-osgi aware dbs.

The advantage of having a separate bundle, though, is that you won't normally have to rev the DBAccess bundle across revs of the driver. Just plop in the new driver jar (or adjust it to have its proper exports, etc.) and you should be good to go.

The code looks fine (although I clearly need to reorg the abstract DSF class from out of the derby package so that it is more reusable. I have been intending to do that but haven't gotten around to it, yet :-(.

If you attach a jar with just the two classes that you wrote then I could check in a postgres supported platform. (It would be a longer process to get the postegres code through IP review, though, because you didn't write it.)

Thanks,
-Mike

Comment 6 Bryan Hunt 2011-11-16 23:24:25 EST

I also need and OSGi based PostgreSQL JDBC driver, so I created a project on GitHub that takes a similar approach to the original Derby work.  I'm currently wrapping the PostgreSQL 9.1-901 JDBC 4 driver and it seems to be working.  There's still some refactoring to do, but maybe this is a usable solution.

https://github.com/BryanHunt/dbaccess

Comment 7 Nobody - feel free to take it 2012-01-18 19:39:30 EST

Hi,

I also did basically the same as Bryan did (without knowing). However, I have a very different approach of building the driver and I have a lot of additional stuff + automatic integration tests:

* building the driver bundle from binary upstream source at build time
* providing networking extensions from Russel Francis (http://www.metro-six.com/products/labs/pg-inet-types)
* providing a simple implementation for OSGi rfc #122 (DataSourceFactory service)
* providing mapping support for EclipseLink (advanced DatabasePlatform + ConnectionCustomizer + Converter)

I verified at least with pax-exam running Apache Felix for automatic testing that the full stack works as well as manual tested basic stuff from within GlassFish 3.1.2 using OSGi bundles only.

Additionally I can produce the same for every existing driver version very easily by just changing configuration.

My code is over here (currently using 9.1-901.1-JDBC4):

https://github.com/ancoron/pg-inet-maven/tree/develop

I already pushed a first release candidate of the resulting artifacts into here:
https://oss.sonatype.org/content/repositories/releases/org/ancoron/postgresql/

Please take a look at it. If you see points to be improved, stuff that is missing, ... please don't hesitate to say it or use the issue tracker on github.


Cheers,

    Ancoron

Comment 8 Rafal Krzewski 2012-02-09 18:19:11 EST

Hi, I've also tried my hand at adding PostgreSQL support to Gemini. Now the developers have a few options to choose from :)

For the impatient, here's the source code: https://github.com/rkrzewski/gemini-dbaccess

I've followed the design of MySQL thin adapter bundle that depends on external driver bundle.

I've also prepared several driver bundles. Each driver bundle contains jar file downloaded from http://jdbc.postgresql.org, license file and OSGi manifest.

I've packaged drivers for PostgreSQL 8.4, 9.0 and 9.1 in two flavors: jdbc3 and jdbc4. JDBC3 is used in J2SE-1.4 and J2SE-1.5 environments and JDBC4 in Java2SE-1.6 and above. It is not possible to couple both drivers (jdbc3+jdbc4) in a single bundle because they use the same package name, but it is possible to install two driver bundles in the same framework - I made jdbc3 driver export it's packages with major version 3 and jdbc4 with major version 4. I've also decided to include .jdbc3/.jdbc4 suffix in bundle symbolic name and keep the version of the bundle matched to original Postgresql driver version.

Regarding versions of package exports I've tried to follow semantic versioning recommendations from OSGi specification. For that purpose I've compared APIs provided by subsequent driver releases using CLIRR (http://clirr.sourceforge.net/). The results of the analysis with some further notes are in the repository, in the invidual driver bundle projects. It turned out PostgreSQL developers did a really decent job in keeping backward compatibility, I only needed to make some minor version increments of package versions. Regarging the set of packages being exported, I took cue from the driver's JavaDocs. The ant build contains a section that explicitly lists the packages that the driver developers consider to be the public API. That really made my work easier :). The lineup of API packages have remained constant over releases 8.4 to 9.1.

The DSF adapter bundle can work with each of the 6 driver bundles provided. It uses OSGi bundle wiring API to find out which bundle is the actual provider of org.postgresql package and report this bundle's version in osgi.jdbc.driver.version property of the DataSourceFactoryService

I'd be happy to contribute my work to Gemini project. Please contact me if you are interested.

Comment 9 Eduardo Frazão 2012-04-02 16:39:18 EDT

Hi all!
Will be great if a PostgreSQL JDBC driver become compatible with OSGi and the JDBC Spec. But, will be great if Oracle, SQLServer and so many other JDBC Drivers does so.
Is responsability of Gemini DBAccess project support each driver?