Hi, I am ok with going to the pooled version. Just create a JIRA and do ;-)
Am Donnerstag, den 09.12.2010, 16:46 +0100 schrieb Clemens Wyss: > <param name="shutdownOnClose" value="false"/> > must be removed, too Hmm, I assume this parameter has been removed altogether, right ? Point is: Jackrabbit must IMHO not fiddle with the Derby state because in Sling Derby is installed in its own bundle and - theoretically - there may be other users. Thus, Jackrabbit is not in a position to decide to shutdown Derby. Regards Felix > > Should I JIRA this? > > Regards > Clemens > > > -----Ursprüngliche Nachricht----- > > Von: Clemens Wyss [mailto:[email protected]] > > Gesendet: Donnerstag, 9. Dezember 2010 16:43 > > An: [email protected] > > Betreff: o.a.jr.c.p.db.DerbyPersistenceManager should be replaced with > > o.a.jr.c.p.bundle.DerbyPersistenceManager > > > > Just had a discussion (see below) on the jackrabbit ml. Possibly before > > releasing the next release... > > > > Regards > > Clemens > > > > Von: Clemens Wyss [mailto:[email protected]] > > Gesendet: Donnerstag, 9. Dezember 2010 16:34 > > An: [email protected] > > Betreff: AW: o.a.jr.c.p.pool.DerbyPersistenceManager not "compatible" with > > o.a.jr.c.p.db.DerbyPersistenceManager? > > > > > So s/db/bundle/ and this should work. > > I can confirm that bundle and pool cope well ! > > > > Then we at Sling should switch from "db" to "bundle" ;-) Sling (launchpad), > > per default (upon bootstrapping), still creates a repository.xml with > > "db"... > > > > > > Von: [email protected] [mailto:[email protected]] Im > > Auftrag von Justin Edelson > > Gesendet: Donnerstag, 9. Dezember 2010 16:14 > > An: [email protected] > > Betreff: Re: o.a.jr.c.p.pool.DerbyPersistenceManager not "compatible" with > > o.a.jr.c.p.db.DerbyPersistenceManager? > > > > > > On Thu, Dec 9, 2010 at 10:07 AM, Jukka Zitting > > <[email protected]<mailto:[email protected]>> wrote: > > Hi, > > > > > > On 09/12/10 15:54, Clemens Wyss wrote: > > I create a copy of a jackrabbit repository with > > org.apache.jackrabbit.core.RepositoryCopier (using > > org.apache.jackrabbit.core.persistence.pool.DerbyPersistenceManager). > > > > Trying to access this copy with > > org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager > > fails. > > > > Testcase: > > 1) create a repository.xml file with > > org.apache.jackrabbit.core.persistence.pool.DerbyPersistenceManager > > 2) start/stop jackrabbit > > 3) change repository.xml to > > org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager > > 4) start jackrabbit > > > > I don't understand why pooled access should yield different persisted > > data... > > > > Bug or feature? > > > > Bug, the only difference between these persistence managers should be the > > way they manage the database connection. > > > > Can you file an issue about this with more details like the exact error > > messages you're seeing and the Jackrabbit version you're using? > > > > BR, > > > > Jukka Zitting > > > > I hate to contradict Jukka, but I'm under the impression that > > o.a.j.core.persistence.db.* use a different schema than > > o.a.j.core.persistence.pool.*. o.a.j.core.persistence.pool.* uses the same > > scheme as o.a.j.core.persistence.bundle.*. > > > > So s/db/bundle/ and this should work. > > > > o.a.j.core.persistence.db.* is deprecated now (see JCR-2802) > > > > Justin >
