On Thu, Jul 17, 2008 at 9:09 PM, Matej Knopp <[EMAIL PROTECTED]> wrote: > 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.
DataSource et al are fine for client/user applications. jackrabbit OTOH is an infrastructure app and therefore needs exclusive control over the persistence layer (i.e. jdbc connections in this case). with hindsight i regret i did implement the jdbc persistence manager in the first place (it was meant as a proof of concept only). but that's a different story and just my very personal view ;) cheers stefan > > -Matej >
