jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: Plain Java as deployment/configuration platform (Was: [jira] [Created] (OAK-87) Declarative services and OSGi configuration)
Date Mon, 07 May 2012 12:36:03 GMT

>What I'm trying to achieve is for us to be easily able to support all
>such deployments without trying to force everything to go through a
>single mechanism like the repository.xml in Jackrabbit 2.x.

Yes, the repository.xml was problematic (for multiple reasons).

>It's fine to have a utility class like
>the MKF that interprets custom "repository URLs", but having things
>like the log wrapper depend on the MKF essentially hardwires that
>single configuration mechanism to the implementation.

If you want to support "pluggability" without having to recompile the
application whenever you want to switch to a new implementation, then
there has to be some kind of "standard", that is, some kind of class. But
the MicroKernelFactory (as it is now) shouldn't be used within MicroKernel
implementation itself, on this I agree.

>Note that in JDBC the DataSource interface was explicitly introduced
>for "the advantage of making the application code independent of a
>particular JDBC driver and JDBC technology URL." [1]

This sentence is out of context here. It is under the topic "JNDI for
naming databases". JNDI is an alternative way to configure a database.
DataSource, and JNDI, isn't meant as a replacement for JDBC. I would argue
most applications don't use JNDI.

>Nowadays few JDBC applications acquire their database connections
>directly using DriverManager.getConnection() and a database URL.

That's your view. I believe most, specially simple applications use
DriverManager.getConnection. Most tutorial use the DriverManager, such as:

http://docs.oracle.com/javase/tutorial/jdbc/basics/connecting.html "The
samples in this tutorial use the DriverManager class instead of the
DataSource class because it is easier to use and the samples do not
require the features of the DataSource class." - I fully agree with the
"easy to use" part.

Also, all databases support using DriverManager.getConnection(). Not all
support a DataSource, or JNDI. Not to talk about OSGi :-) Also, in many
cases, the DataSource is configured using a database URL.

>It's of course also possible for an application to use
>DriverManager.getConnection() ..., but then you lose all the extra
>and functionality provided by the deployment container.

That is, if you use a deployment container (JNDI,...) at all.

>To summarize, I think our default component model should look more
>like DataSource than DriverManager in JDBC.

What I want to avoid is people hardcoding the implementation class itself
in their application. Instead, either JNDI, OSGi, or another, lightweight
solution should be used, that allows to easily switch to another JCR


View raw message