True, but a lot of projects (Eclipse since the move to OSGi, Apache
since Felix/Karaf etc became more prominent, Spring, ...) have now jars
which have correct OSGi meta infos already.

Dave Cramer from the postgres JDBC driver encouraged me to send a pull
request and he will merge it onto the current branch. So we can use the
JDBC driver directly in the future. I'm just waiting for a answer here
on this list how to handle the properties correctly.

I didn't talk about the DataSource, the OSGi service doesn't get
unregistered, which is at least bad style.


Jürgen

Am 12.04.2014 13:05, schrieb Balázs Zsoldos:
> "a postgres driver which is repackaged by somebody else": These
> re-packaged jar files normally contain only extra MANIFEST headers
> (Import-Package and Export-Package). The bytecode and the source is
> the same as in the original. Are you a contributor of PostgreSQL JDBC
> driver? The next version will contain the necessary MANIFEST headers?
> If not, we must keep using re-packaged jars.
>
> "pax implementation doesn't clean up after itself": I do not think
> that the one who serves DataSourceFactory should clean anything up.
> The pax implementation only works as a factory. In my opinion, It is
> the responsibility of the client modules to close any requested
> resources when the DataSourceFactory service is unregistered.
>
> Regards,
> Balazs Zsoldos
>
>
>
> On Sat, Apr 12, 2014 at 1:16 AM, Jürgen Rose <[email protected]
> <mailto:[email protected]>> wrote:
>
>     The thing is, I don't want to have an additional bundle, it would
>     be nice if it works out of the box. And I definitely don't want to
>     have a postgres driver which is repackaged by somebody else.
>
>     Additionally, the pax implementation doesn't clean up after
>     itself, and not all properties are supported.
>
>
>     Jürgen
>
>     Am 12.04.2014 01:02, schrieb Balázs Zsoldos:
>>     Hi,
>>
>>     You might do a job that is already done.
>>
>>     Look for "postgresql" on maven central. I think you will find
>>     adapter for the postgresql jdbc driver.
>>
>>     E.g.:
>>
>>       * PostgreSQL JDBC
>>         JAR: 
>> http://search.maven.org/#artifactdetails%7Corg.apache.servicemix.bundles%7Corg.apache.servicemix.bundles.postgresql%7C9.3-1100-jdbc41_1%7Cbundle
>>       * Adapter that registers the DataSourceFactory
>>         service: 
>> http://search.maven.org/#artifactdetails%7Corg.ops4j.pax.jdbc%7Cpax-jdbc-postgresql%7C0.3.0%7Cbundle
>>
>>     I tried it before and the two bundles worked well together.
>>
>>     Regards,
>>     *Zsoldos Balázs*
>>
>>
>>     On Sat, Apr 12, 2014 at 12:20 AM, Jürgen Rose
>>     <[email protected] <mailto:[email protected]>> wrote:
>>
>>         Hi,
>>
>>         I'm Jürgen, new on this list and I'm currently osgifying the
>>         postgresql
>>         jdbc driver (https://github.com/pgjdbc/pgjdbc/issues/71).
>>
>>         I have some questions regarding the DataSourceFactory. There
>>         are a bunch
>>         of predefined property names defined like JDBC_DATABASE_NAME
>>         which is
>>         databaseName, JDBC_PORT_NUMBER is portNumber, and so on.
>>
>>         As far as I understand these are basically the Properties
>>         which are
>>         defined as required/optional properties in the JDBC spec.
>>
>>         What is the policy regarding additional properties, should
>>         they just be
>>         passed on as well? What about unsupported properties, should
>>         they just
>>         be ignored, or lead to an exception?
>>
>>         Whan I look at the h2 code it is a bit of a mix:
>>         
>> http://grepcode.com/file_/repo1.maven.org/maven2/com.h2database/h2/1.3.174/org/h2/util/OsgiDataSourceFactory.java/?v=source
>>
>>         The implementation of eclipselabs for postgres uses
>>         introspection to set
>>         the properties:
>>         
>> https://github.com/BryanHunt/dbaccess/blob/master/bundles/org.eclipselabs.dbaccess.postgresql/src/org/eclipselabs/dbaccess/postgresql/AbstractDataSourceFactory.java
>>         and also throws an error if a property doesn't exist.
>>
>>         What is the canonical approach here?
>>
>>         best regards
>>         Jürgen
>>         _______________________________________________
>>         OSGi Developer Mail List
>>         [email protected] <mailto:[email protected]>
>>         https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
>>
>>     _______________________________________________
>>     OSGi Developer Mail List
>>     [email protected] <mailto:[email protected]>
>>     https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>     _______________________________________________
>     OSGi Developer Mail List
>     [email protected] <mailto:[email protected]>
>     https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to