On Sat, Apr 12, 2014 at 11:05 PM, Jürgen Rose <[email protected]>wrote:
> 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. > Can you clarify what you mean by this? The DataSourceFactory service doesn't get unregistered when the bundle stops? That's actually impossible... OSGi services are automatically unregistered when the publishing bundle stops. Or to put it another way, only active bundles can publish services. So, just because you don't see the call to ServiceRegistration.unregister() in the code doesn't mean the service is left registered. Regards, Neil > > > 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]>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]>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] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >> >> >> >> _______________________________________________ >> OSGi Developer Mail >> [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 > [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
