jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@day.com>
Subject Re: Version.revert()
Date Mon, 05 May 2008 14:30:10 GMT
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