On Thu, Jul 17, 2008 at 7:07 PM, Matej Knopp <[EMAIL PROTECTED]> wrote: > Well, > > i think the easiest solution would be if jackrabbit instantiated and > maintained DataSource instances. This gives the most flexibility. > > If someone wants to get a data source from JNDI it would be only > matter of using the right (proxied) data source. > > <DataSource id="ds1" class="...JndiDataSource"> > <param name="jndiName" value="..."/> > </DataSource> > > or you can have datasource from the connection pool, e.g. > <DataSource id="ds2" class="...C3P0DataSource"> > <param name="url" value="jdbc:postgresql:jackrabbittest"/> > <param name="user" value="postgres"/> > <param name="password" value="postgres"/> > </DataSource> > > Just because jackrabbit would manage the data sources it doesn't mean > it should do the pooling, etc. The DataSources it instantiates could > be just simple proxies to JNDI, spring, or whatever else that would > manage the datasources. > > This way jackrabbit could leverage container data source management > without having any direct dependencies that would prevent it from > running standalone.
If you get database connection pooling in Jackrabbit without DataSources (using the aforementioned commons-dbcp for example), why do you need a explicit DataSource configuration inside the repository.xml then? Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
