That may explain our problem because we are using jboss to manage the
connections and I was told that they are purely transactional. I would
like to avoid using a Database Persistence manager but while looking
through the API I saw an Object Persistence Manager. Do you happen to
know if it is non-transactional also? And I'll be glad to submit this
as a jira issue but I have never done so before, can you point me to a
place where I can get started with it?
Thanks again,
Brett
On Mon, May 5, 2008 at 2:18 PM, Conoly, Brett
<[EMAIL PROTECTED]> wrote:
> I'm sorry for another submit but can anyone see anything wrong with
our
> configuration? We are really stuck on this and it is imperative that
we
> get this solved.
i would suggest that you use BundleDbPersistenceManager instead of
BundleFSPersistenceManager since the latter is non-transactional which
might lead to data corruption. i further noticed that there's a
<Security>
tag missing in your config.
but none of above does explain the problems your experiencing.
i ran your test case against jackrabbit trunk using your configuration.
everything worked as expected. here's my console output:
BEFORE **********************
/TestFolder/TestFile
FILE TEXT CONTENT
*****************************
AFTER SAVE*******************
/TestFolder/TestFile
FILE TEXT CONTENT
Mon May 05 15:02:45 CEST 2008
*****************************
AFTER CHECKIN****************
/TestFolder/TestFile
FILE TEXT CONTENT
Mon May 05 15:02:45 CEST 2008
*****************************
please note that your test case was not complete,
the creation of the nt:file node is missing.
what jackrabbit version are you using?
please create a jira issue, provide all relevant information and include
a complete test case. i'll then give it another try to reproduce the
issue.
cheers
stefan
> Thanks in advance,
> Brett
>
>
>
> Currently we aren't using a data store, we're just using a simple
> BundleFsPersistenceManager. And we are not using spring modules in
our
> application. Here is our configuration for our repository.
> <Repository>
> <FileSystem
> class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
>
> <param name="path" value="${rep.home}/repository"/>
>
> </FileSystem>
> <AccessManager
> class="org.apache.jackrabbit.core.security.SimpleAccessManager">
> </AccessManager>
> <LoginModule
> class="org.apache.jackrabbit.core.security.SimpleLoginModule">
> <param name="anonymousId" value="anonymous"/>
> </LoginModule>
> </Security>
> <Workspaces rootPath="${rep.home}/workspaces"
> defaultWorkspace="webcenter"/>
> <Workspace name="${wsp.name}">
> <FileSystem
> class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> <param name="path" value="${wsp.home}"/>
> </FileSystem>
> <PersistenceManager
>
class="org.apache.jackrabbit.core.persistence.bundle.BundleFsPersistence
> Manager">
> </PersistenceManager>
> <SearchIndex
> class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
> <param name="path" value="${wsp.home}/index"/>
> </SearchIndex>
> </Workspace>
> <Versioning rootPath="${rep.home}/version">
> <FileSystem
> class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> <param name="path" value="${rep.home}/version" />
> </FileSystem>
> <PersistenceManager
>
class="org.apache.jackrabbit.core.persistence.bundle.BundleFsPersistence
> Manager">
> </PersistenceManager>
> </Versioning>
> <SearchIndex
> class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
> <param name="path" value="${rep.home}/repository/index"/>
> </SearchIndex>
> </Repository>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Stefan Guggisberg
> Sent: Friday, May 02, 2008 8:43 AM
> To: [email protected]
> Subject: Re: Version.revert()
>
> On Fri, May 2, 2008 at 2:25 PM, Conoly, Brett
> <[EMAIL PROTECTED]> wrote:
> > Hmmm, we did find out that most of the problems that I sent you
> earlier
> > were not actually the cause of the problem, here's a better
> > explination...
> > We were checking our versions and going through some test cases on
an
> > nt:file and we noticed that every time that we used Node.checkin()
it
> > ended up removing the content.
> > We can run through and change the jcr:content -> jcr:data property
as
> > many times as we want on a checked-out node and viewing it through
> > webdav or any other means we always have the updated content.
> > The problem we're having is that when we use the Node.checkin() it
> seems
> > to remove the content completely. We don't get any
>
> this seems to be the same issue as reported in another thread:
>
http://www.nabble.com/Problems-with-Cloning-of-folders-within-workspaces
> -tt16921068.html#a16952272
>
> however, i haven't been able to reproduce it. i guess it's
> configuration dependent/DataStore related...
>
> cheers
> stefan
>
> > PathNotFoundExceptions or anything like that, the jcr:content ->
> > jcr:data property is just empty. This is the same for webdav
also.
> > The way we are picturing it, every nt:file has a base version.
> Whether
> > this base version is checked out or checked in we were thinking
that
> > retrieving it through the session.getItem(path) or
> root.getNode(relPath)
> > would give us a normal nt:file in which we could get the
jcr:content
> ->
> > jcr:data property.
> > Unfortunately, this is not the case as stated earlier.
> > If a Node is checked-in do we have to get the frozen node of that
> > version and then get the content through there? And if so, why
> doesn't
> > the webdav servlet do that?
> > Thanks again for your help.
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tobias
> > Bocanegra
> >
> >
> > Sent: Friday, May 02, 2008 6:26 AM
> > To: [email protected]
> > Subject: Re: Version.revert()
> >
> > On 5/1/08, Conoly, Brett <[EMAIL PROTECTED]> wrote:
> > > That would be it, I was relaying the question from a coworker
who
> for
> > > some reason can't get on this users list. You are correct, it
is
> > > Node.restore() that I'm asking about. But it seems that it's
not
> > > necessarily this method but somehow when we write byte[] to the
> > content
> > > node's data property it is fairly consistently not working.
> > Everything
> > > seems to go through fine but then when we try to read the
content,
> > > through webdav or the api, it is completely empty.
> > > Does anyone know a reason for this?
> > > thanks
> > as i said,
> > please provide an example or test case, so we can reproduce your
> issue.
> > regards, toby
> >
> > >
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Tobias
> > > Bocanegra
> > > Sent: Thursday, May 01, 2008 3:13 PM
> > > To: [email protected]
> > > Subject: Re: Version.revert()
> > >
> > > hi,
> > > there is no Version.revert() method. maybe you mean
Node.restore()
> ?
> > > can you provide a more specific example or test case?
> > >
> > > --
> > > regards, toby
> > >
> > > On 5/1/08, Conoly, Brett <[EMAIL PROTECTED]>
wrote:
> > > > This is just a very general question but has anyone had any
> > problems
> > > > with the Version.revert() function?
> > > >
> > > > We have had several instances where a revert seems to just
> delete
> > the
> > > > content somehow.
> > > >
> > > > Thanks
> > > >
> > > >
> > >
> >
>
