Am 30.06.2011 08:55, schrieb Daniel Plappert:
What I understood so far is: I have to create a service that provides
the datasource. But, what if the datasource has to be configured by
someone else? Not me, for e.g. if I want to "sell" an application
based on OSGI, the datasource must be configured by the buyer's
admin, not me. That's why I came up with tomcat (I know it's not an
OSGI web container). With tomcat the admin can declare a jdbc
datasource which can be accessed via JNDI in the webapp. My question
is, is it possible to do something similar with OSGI? The datasource
must be configurable.
Sure - you can configure a datasource in any Java EE web container, but
the Java EE spec does not define the implementation details. Tomcat's
configuration doesn't work for GlassFish, and vice versa.
The OSGi specs do not define how to configure the OSGi container or
individual services, but they do define a Configuration Admin service
which lets you configure services at runtime.
See this presentation for an overview (in German):
http://www.iks-gmbh.com/files/pdf/jax09_osgi_vortrag_der_iks.pdf
The OSGi Enterprise Spec defines a JDBC Service providing a
DataSourceFactory. (This is not implemented in Aries AFAIK. Eclipse
Gemini has a JDBC Service, but they only support Derby out of the box,
and you have to write our own provider for other JDBC drivers, as most
of them are not OSGi-ready.)
Is creating i.e. a database.properties file which is read by my OSGI
service the only way to achieve this goal?
Certainly not the only way, but maybe the easiest one. I like my
applications to have one central config file (properties or XML, as the
case may be), so why not put the datasource properties into the same
file with the rest of your configuration rather than using a different
(albeit standardized) method to configure your datasource.
The "best" solution depends on how flexible your system is required to
be. Should your customers be able to switch between PostgreSQL, MySQL
and Derby? Then they need to select and configure the appropriate JDBC
driver, and the JDBC Service might help.
Do you need the full dynamics of OSGi, with bundles coming and going at
runtime? Then a central config file may not work...
Regards,
Harald
