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. > 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
