I wish it was that simple ;) Startup and deployment on jboss is ok, but when
i try to log in i get an exception. Here is the stack trace :

1) org.nuxeo.ecm.core.api.ClientException : Failed to create document
workspaces
at org.nuxeo.ecm.core.api.AbstractSession.createDocument(
AbstractSession.java:558)

2) org.nuxeo.ecm.core.api.DocumentException : javax.jcr.RepositoryException:
failed to resolve path ecm:children/default-domain/ relative to /ecm:root:
Empty path element: ecm:children/default-domain/: Empty path element:
ecm:children/default-domain/
at org.nuxeo.ecm.core.repository.jcr.JCRSession.resolvePath(JCRSession.java
:290)

3) javax.jcr.RepositoryException : failed to resolve path
ecm:children/default-domain/ relative to /ecm:root: Empty path element:
ecm:children/default-domain/: Empty path element:
ecm:children/default-domain/
at org.apache.jackrabbit.core.NodeImpl.resolveRelativeNodePath(NodeImpl.java
:257)

4) org.apache.jackrabbit.name.MalformedPathException : Empty path element:
ecm:children/default-domain/
at org.apache.jackrabbit.name.ParsingPathResolver.getElement(
ParsingPathResolver.java:54)

Hope this helps,
Cedric


On 6/11/07, Bogdan Stefanescu <[EMAIL PROTECTED]> wrote:


Normally, this should work by simply replacing jackrabbit jars.

Bogdan

Cédric Joyau wrote:
> Hi lads,
>
> Jackrabbit's perfs have been improved thanks to the bundle managers
> included in version 1.3, but the current version of Nuxeo Core
> supports Jackrabbit 1.2, so when do you plan to support the new one ?
> I'll do some benchs when it's available ;)
>
> --
> Cédric
>
>
> On 6/10/07, *Cédric Joyau* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>     I agree with you Florent, since Jackrabbit sessions are already
>     optimized there's no need to do some pooling on Nuxeo side. My
>     concern is that Jackrabbit maintains a single connection to the
>     database on its side, and that's where we could have a bottleneck.
>     I'll test some BundlePersistenceManagers and see what comes up.
>
>     Cédric
>
>
>     On 6/9/07, *Florent Guillaume* <[EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>> wrote:
>
>         You're both talking of pooling at different levels.
>
>         Cédric talks about pooling inside Jackrabbit of the jdbc
>         connection
>         it maintains to its underlying database. This is Jackrabbit's
>         internal sauce, and its responsibility.
>
>         Bogdan talks about pooling JCR session at the Nuxeo level.
>
>         Actually I doubt this latter pooling is needed. One needs
>         pooling when:
>         - creating a new session is expensive -- but it's not for
>         Jackrabbit,
>         - reusing an old session gives the benefit of reusing caches
>         -- but
>         the caches in Jackrabbit are still maximally shared by all
>         sessions
>         when possible anyway, there are internal Jackrabbit
datastructures
>         for that (see SharedItemStateManager).
>
>         So unless someone proves to me that session pooling is needed,
I'm
>         not going to lose sleep over this :)
>
>         Florent
>
>
>         On 8 Jun 2007, at 17:49, Cédric Joyau wrote:
>         > JackRabbit doesn't handle pooling at its level, at least not
the
>         > SimpleDbPersistenceManager. Discussion takes place over here :
>         >
http://www.mail-archive.com/[EMAIL PROTECTED]/
>         > msg04431.html
>         >
>         > I'm not an expert, but do you think it's possible to use an
>         > existing pooling system and make it work with JackRabbit in
>         Nuxeo ?
>         > (reusing the JBoss one for instance, or using the commons-dbcp
>         > package from the jakarta project). I'll have a deeper look
into
>         > this next week.
>         >
>         > > Any volunteer to test if pooling on jackrabbit session is
>         > improving perfs.? :)
>         >
>         > Well, I am :)
>         >
>         > Cedric
>         >
>         >
>         > On 6/8/07, Bogdan Stefanescu < [EMAIL PROTECTED]
>         <mailto:[EMAIL PROTECTED]> > wrote:
>         > Connections are handled by JBoss JCA implementation.
>         > Nuxeo provides a resource adapter for the underlying
repository
>         > (jackrabbit) that is registered in JBoss.
>         > Then jboss is using a pool of managed connection and also
>         ensure the
>         > repository resource is enlisted on the current transaction.
>         > In fact if I remember well physical connections to jackrabbit
>         > (jackrabbit sessions) are closed when a managed connection
>         > is reused from the pool. So practically there is a JCR
>         session per
>         > request which is closed after the request ends.
>         >
>         > So at nuxeo core level we don't use pooling.
>         > I am not sure if Jackrabbit do some pooling at its level. But
I
>         > think it
>         > should optimize connections to underlying
>         > databases (or other storages)
>         >
>         > Any volunteer to test if pooling on jackrabbit session is
>         improving
>         > perfs.? :)
>         >
>         > Bogdan
>         >
>         >
>         > Cédric Joyau wrote:
>         > > Hi,
>         > >
>         > > I'd like to know how Nuxeo handles connections to
>         datasources and
>         > the
>         > > content repository ... is it a single connection for each
>         one or
>         > it is
>         > > possible to set up a connection pool ? Do you plan to do
some
>         > > performance tracking on this ?
>         > >
>         > > Cheers,
>         > > Cédric
>


_______________________________________________
ECM mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm

Reply via email to