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]> 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 List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
