On Thu, Jul 17, 2008 at 6:47 PM, Thomas Müller <[EMAIL PROTECTED]> wrote: > Hi, > > I am trying to understand both Matej and Alexander / Marcel... > > In my view Jackrabbit should be able to obtain database connections > using a JDBC URL as well as a data source name. If Jackrabbit requires > some kind of connection pooling, that should be integrated in > Jackrabbit - otherwise it is not possible to use Jackrabbit in a > standalone application. Otherwise FirstHop couldn't be started from > the command line.
What should such integration look like? Would you allow the user to chose the connection pooling implementation or would you "hardcode" one? What if user already has connection pooling infrastructure in place (but not one exported by JNDI)? I still don't quite understand what is the big issue with managing DataSource instances. We are not talking about writing an IoC container here. All that would do is a simple map <id> -> <dataSourceInstance> where dataSourceInstance is a simple java bean implementing DataSource. If user wants jndi, the bean would be simple JNDI DataSource proxy. C3P0 or commons-dbcp have their own data source classes already that could be easily configured. Or user could provide a DataSource that would proxy calls to a spring/guice/hivemind managed beans. All of those would be trivial to write and configure. One of the annoyances with jackrabbit apart from the fact that it keeps db connections opened is that it only provides two options to obtain the actual connections. Either through JNDI or it creates the connections on it's own. But there is a good reason why the DataSource interface was introduced. I really don't think it is a good idea to have Jackrabbit creating database connections without having a simple way to override this behavior. -Matej
