Hi, >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 >flexibility >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 implementation. Regards, Thomas
