jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Plain Java as deployment/configuration platform (Was: [jira] [Created] (OAK-87) Declarative services and OSGi configuration)
Date Mon, 07 May 2012 11:31:32 GMT

On Mon, May 7, 2012 at 12:29 PM, Thomas Mueller <mueller@adobe.com> wrote:
> OK, I think I understand. Yes, it should be possible to use that approach,
> even thought I would prefer if most JCR applications don't actually
> hardcode the storage *classes* within the source code of the application,
> because this would complicate using a different JCR implementation.

Agreed. Each application should use the appropriate mechanisms for
their deployment platform. An OSGi app should use service references,
a J2EE app JNDI lookups or dependency injection, etc.

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. That's my
biggest concern over the MicroKernelFactory class and the reason why
I've been trying to reverse the dependency between the MKF and the
various implementation classes. 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.

> As an example, the JDBC API doesn't require an application to hardcode
> any implementation specific classes (the database driver *classes*)
> within the application. Instead, the driver is loaded using the service
> loader, and the database URL is used to open the connection.

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]

Nowadays few JDBC applications acquire their database connections
directly using DriverManager.getConnection() and a database URL.
Instead they get a DataSource reference trough JNDI or some other
deployment-specific mechanism (typically dependency injection) and use
that to acquire connections.

Configuring and managing such DataSources is a deployment concern that
things like J2EE containers have evolved to deal with in quite a bit
of detail without JDBC client applications having to worry about any
of that. It's of course also possible for an application to use
DriverManager.getConnection() or even directly instantiate a
particular Driver class, but then you lose all the extra flexibility
and functionality provided by the deployment container.

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

[1] http://docs.oracle.com/javase/1.3/docs/guide/jdbc/spec2/jdbc2.1.frame3.html


Jukka Zitting

View raw message