jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conoly, Brett" <Brett.Con...@digitalinsight.com>
Subject RE: Version.revert()
Date Mon, 05 May 2008 14:43:05 GMT
Yeah, I'm not completely sure what that means either, but I was told
jboss uses a jca connector and it is transactional which could be
causing the data corruption.

And for the derby persistence manager, that's what we were initially
using and the entire repository got corrupted several times, one of
which the repository couldn't recover from.  Since we have been using
the file system persistence manager this has not happened although we
just noticed that the checkin function was corrupting the data on the
actual file for the File system manager.
Thanks again


On Mon, May 5, 2008 at 4:16 PM, Conoly, Brett
<Brett.Conoly@digitalinsight.com> wrote:
>
>  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

now i am getting confused... ;) what connections are managed by jboss
and why would they be purely transactional?

>  like to avoid using a Database Persistence manager but while looking

why? you could e.g. use jackrabbit's current default configuration which
uses an embedded derby db. it doesn't involve any special deployment
requirements.

>  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

it's file-system based and therefore non-transactional. you can find
more
related information here:
http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ

>  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?

http://jackrabbit.apache.org/issue-tracker.html

thanks
stefan

>  Thanks again,
>  Brett
>
>
>
>  On Mon, May 5, 2008 at 2:18 PM, Conoly, Brett
>  <Brett.Conoly@digitalinsight.com> 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: stefan.guggisberg@gmail.com
>  [mailto:stefan.guggisberg@gmail.com]
>  >  On Behalf Of Stefan Guggisberg
>  >  Sent: Friday, May 02, 2008 8:43 AM
>  >  To: users@jackrabbit.apache.org
>  >  Subject: Re: Version.revert()
>  >
>  >  On Fri, May 2, 2008 at 2:25 PM, Conoly, Brett
>  >  <Brett.Conoly@digitalinsight.com> 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: tripod@day.com [mailto:tripod@day.com] On Behalf Of
Tobias
>  >  >  Bocanegra
>  >  >
>  >  >
>  >  > Sent: Friday, May 02, 2008 6:26 AM
>  >  >  To: users@jackrabbit.apache.org
>  >  >  Subject: Re: Version.revert()
>  >  >
>  >  >  On 5/1/08, Conoly, Brett <Brett.Conoly@digitalinsight.com>
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: tripod@day.com [mailto:tripod@day.com] On Behalf Of
>  Tobias
>  >  >  >  Bocanegra
>  >  >  >  Sent: Thursday, May 01, 2008 3:13 PM
>  >  >  >  To: users@jackrabbit.apache.org
>  >  >  >  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 <Brett.Conoly@digitalinsight.com>
>  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
>  >  >  >  >
>  >  >  >  >
>  >  >  >
>  >  >
>  >
>

Mime
View raw message