On 7.5.12 12:31, Jukka Zitting wrote:
Hi,
On Mon, May 7, 2012 at 12:29 PM, Thomas Mueller<[email protected]> 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.
I like that approach very much. I think it is much more flexible than
having a single mechanism in place which forces things "our way". To
that end I removed the GlobalContext hack in revision 1334962 which
served as kind of a reminder to sort these things out.
AFAICS we currently support plain constructor calls and OSGi for setting
things up. What about also adding support for JSR 330? I think this
could be done similarly to how OSGi support is being done by putting the
wiring code into separate package.
Michael
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
BR,
Jukka Zitting
