Since I implement a specific DataSourceFactory, I know all the properties I have to support, so there is no need for me to make a distinction between common and database specific properties.
But the H2 implementation is exactly what brought me to the question! The behaviour there is inconsistent in itself. best regards Jürgen On 14.04.2014 17:01, Balázs Zsoldos wrote: > As much as I saw, the property options of DataSourceFactory were > defined based on the Oracle JDBC driver. However, not all of the > database engines have the same configuration properties. Therefore it > should be possible to use additional properties in the > DataSourceFactory. I would ask in that case to list those properties > in a Constants class (that has a bit more specific name that simply > Constants :)). > > It is interesting that in the H2 implementation the creation of a > DataSource fails if JDBC_ROLE_NAME or JDBC_DATASOURCE_NAME is defined, > but it does not care if another unknown property is defined. See > OSGiDataSourceFactory in the H2 jar. > > When I created the second version of the component > <https://github.com/everit-org/osgi-jdbc-dsf> that can create > DataSource or XADataSource, I added an optional String[] configuration > option where property entries could be defined. I needed it as some > JDBC drivers support such properties that are not listed as constant > in the DataSourceFactory interface. > > Regards, > Balazs > > > On Mon, Apr 14, 2014 at 4:28 PM, Peter Kriens <[email protected] > <mailto:[email protected]>> wrote: > > This is an interesting question I ran into recently as well. > Before that point, I always assumed we used properties so you > could add additional properties and ignore the ones you did not > recognize. This has worked well for OSGi so far. However, when > working in this area I noticed some implementers whine when they > see properties they do not recognize, and I could also understand > that rationale. > > So I think you should ignore any properties you do not recognize > since this has been the OSGi way from the beginning. However, > since the user is fully aware of what he is configuring I think > there is no real problem if you take another approach. > > In short, as far as I know this question was never considered > because it seemed obvious to ignore unrecognized parameters :-) > > Kind regards, > > Peter Kriens > > > On 12 apr. 2014, at 00:20, 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] > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
