Re: getting the latest version of a checkedout node
I am sorry. I didn't realize I was reading the dev list when I was posting this. Will keep it in mind next time. I had already tried your approach with multiple workspaces. The problem with that is, I don't want a workspace for every user, since there might be a lot of users. So I tried to create a workspace just for the checkedout nodes. Kind of temporary store. But I use a lot of reference properties in my nodes, so I couldn't just clone the nodes to the temp. workspace since then the references are missing. Cross-workspace references aren't possible right? So this option isn't working out for me either. thnx David Nuescheler wrote: > > Hi J, > > I think that your explanations point into the direction of multiple > workspaces. If user A has a workspace A that user can make > modifications in his workspace without user B in workspace B > can see the changes. As soon as user A checks something > into the version store user B can check it out and look at it > using merge() or update(). > > Does that suit your use case? > > regards, > david > > -- View this message in context: http://www.nabble.com/getting-the-latest-version-of-a-checkedout-node-tf2227841.html#a6203970 Sent from the Jackrabbit - Dev forum at Nabble.com.
Re: getting the latest version of a checkedout node
I don't think so. This is actually restoring the node, so the current node is overwritten with the older version. I just want to read the latest version of a node before it was checked out. In my application users are reading nodes, the checkedout state of a node shouldn't be visable for the users. When a user has checked out a node and is changing it, all other users should get the latest version before it was checked out, when they request the node. Only when the node is checked in again they get the one with changes. Tobias Bocanegra wrote: > > you're probably looking for: > > Node.restore(node.getBaseVersion()); > > regards, toby > > On 9/6/06, J Kuijpers <[EMAIL PROTECTED]> wrote: >> >> Hello, when the property jcr:isCheckedOut of a node is true, I want to >> retrieve this node without the changes which are possibly made during the >> checkout state. So I want to retrieve the node as it was, when it was >> last >> checked in. Only when the checkedout node is checkedin the changes are >> final >> so then I want to retrieve the node with ithe changes. >> >> Is this possible? If so, how would I achieve this? I am looking at the >> frozennode property, am I on the right track? >> -- >> View this message in context: >> http://www.nabble.com/getting-the-latest-version-of-a-checkedout-node-tf2227841.html#a6173979 >> Sent from the Jackrabbit - Dev forum at Nabble.com. >> >> > > > -- > -< [EMAIL PROTECTED] >--- > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel > T +41 61 226 98 98, F +41 61 226 98 97 > ---< http://www.day.com >--- > > -- View this message in context: http://www.nabble.com/getting-the-latest-version-of-a-checkedout-node-tf2227841.html#a6187272 Sent from the Jackrabbit - Dev forum at Nabble.com.
getting the latest version of a checkedout node
Hello, when the property jcr:isCheckedOut of a node is true, I want to retrieve this node without the changes which are possibly made during the checkout state. So I want to retrieve the node as it was, when it was last checked in. Only when the checkedout node is checkedin the changes are final so then I want to retrieve the node with ithe changes. Is this possible? If so, how would I achieve this? I am looking at the frozennode property, am I on the right track? -- View this message in context: http://www.nabble.com/getting-the-latest-version-of-a-checkedout-node-tf2227841.html#a6173979 Sent from the Jackrabbit - Dev forum at Nabble.com.
Re: altering ceckoutstate and uuid on importxml
I have done some testing with this. Found the jcr:uuid isn't overwritten but the jcr:ischeckedout is. Nicolas Toper wrote: > > Actually, the backup tool is doing this, but its integration in core is > still discussed there. I would suggest to wait a few days since I have > done > already the code for this. > > Nico > > On 9/1/06, J Kuijpers <[EMAIL PROTECTED]> wrote: >> >> >> There's no way of influence these props on the fly in some way? I need >> the >> node to be checkedin and give it my own uuid. Don't want to alter them >> afterwards for performance reaons >> >> >> >> Nicolas Toper wrote: >> > >> > Hi, >> > >> > They will be overwritten. >> > >> > Cheers, >> > Nico >> > my blog! http://www.deviant-abstraction.net !! >> > >> > On 9/1/06, J Kuijpers <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> We use the importxml method on the sessionimpl to import some nodes in >> >> jackrabbit. I want to have some influence on the uuid and >> checkedoutstate >> >> on >> >> the main node during importing. >> >> Can I do something like the xml below or will the jcr:ischeckedout and >> >> jcr:uuid be overwritten during the importxml? >> >> >> >> >> >>bla >> >>blabla >> >> >> >> >> >> thx >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/altering-ceckoutstate-and-uuid-on-importxml-tf2201714.html#a6096006 >> >> Sent from the Jackrabbit - Dev forum at Nabble.com. >> >> >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/altering-checkoutstate-and-uuid-on-importxml-tf2201714.html#a6096141 >> Sent from the Jackrabbit - Dev forum at Nabble.com. >> >> > > > -- > a+ > Nico > my blog! http://www.deviant-abstraction.net !! > > -- View this message in context: http://www.nabble.com/altering-checkoutstate-and-uuid-on-importxml-tf2201714.html#a6097318 Sent from the Jackrabbit - Dev forum at Nabble.com.
Re: altering ceckoutstate and uuid on importxml
There's no way of influence these props on the fly in some way? I need the node to be checkedin and give it my own uuid. Don't want to alter them afterwards for performance reaons Nicolas Toper wrote: > > Hi, > > They will be overwritten. > > Cheers, > Nico > my blog! http://www.deviant-abstraction.net !! > > On 9/1/06, J Kuijpers <[EMAIL PROTECTED]> wrote: >> >> >> We use the importxml method on the sessionimpl to import some nodes in >> jackrabbit. I want to have some influence on the uuid and checkedoutstate >> on >> the main node during importing. >> Can I do something like the xml below or will the jcr:ischeckedout and >> jcr:uuid be overwritten during the importxml? >> >> >>bla >>blabla >> >> >> thx >> -- >> View this message in context: >> http://www.nabble.com/altering-ceckoutstate-and-uuid-on-importxml-tf2201714.html#a6096006 >> Sent from the Jackrabbit - Dev forum at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/altering-checkoutstate-and-uuid-on-importxml-tf2201714.html#a6096141 Sent from the Jackrabbit - Dev forum at Nabble.com.
Re: altering checkoutstate and uuid on importxml
xml file uploaded J Kuijpers wrote: > > We use the importxml method on the sessionimpl to import some nodes in > jackrabbit. I want to have some influence on the uuid and checkedoutstate > on the main node during importing. > Can I do something like the xml below or will the jcr:ischeckedout and > jcr:uuid be overwritten during the importxml? > > > >bla >blabla > > > > thx > http://www.nabble.com/user-files/235835/xml.txt xml.txt -- View this message in context: http://www.nabble.com/altering-checkoutstate-and-uuid-on-importxml-tf2201714.html#a6096116 Sent from the Jackrabbit - Dev forum at Nabble.com.
altering ceckoutstate and uuid on importxml
We use the importxml method on the sessionimpl to import some nodes in jackrabbit. I want to have some influence on the uuid and checkedoutstate on the main node during importing. Can I do something like the xml below or will the jcr:ischeckedout and jcr:uuid be overwritten during the importxml? bla blabla thx -- View this message in context: http://www.nabble.com/altering-ceckoutstate-and-uuid-on-importxml-tf2201714.html#a6096006 Sent from the Jackrabbit - Dev forum at Nabble.com.
Re: problem retrieving nodes from different workspaces
You're right, that I didn't find that myself. Thanks for spotting it :) Marcel Reutegger-3 wrote: > > Your repository.xml file is broken. > > You have: > > class="org.apache.jackrabbit.core.state.db.DerbyPersistenceManager"> > value="jdbc:derby:${rep.home}/version/db;create=true"/> > > > > > A fixed value for the parameter 'schemaObjectPrefix' will cause > Jackrabbit to write content of multiple workspaces into the same > table, thus possibly overwriting content. > > You must use a value that includes the workspace name as a variable. > > E.g. the sample configuration uses this: > > > > See also: > https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit/src/main/config/repository.xml > > Using the sample repository.xml the test works fine even with a > shutdown in between. > > regards > marcel > > > > J Kuijpers wrote: >> Were you able to reproduce our problem? >> >> >> Jukka Zitting-3 wrote: >>> Hi, >>> >>> On 8/28/06, J Kuijpers <[EMAIL PROTECTED]> wrote: >>>> Supplied repository.xml and runnable MultipleWorkspaceTest.java >>>> http://www.nabble.com/user-files/235783/repository.xml repository.xml >>>> http://www.nabble.com/user-files/235784/MultipleWorkspaceTest.java >>>> MultipleWorkspaceTest.java >>> The MultipleWorkspaceTest.java file appears to be empty. Could you >>> resend it, inline if necessary? >>> >>> BR, >>> >>> Jukka Zitting >>> >>> -- >>> Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] >>> Software craftsmanship, JCR consulting, and Java development >>> >>> >> > > > -- > Marcel Reutegger > Day Management AG > Barfuesserplatz 6, 4001 Basel Switzerland > > [EMAIL PROTECTED] > www.day.com > > T 41 61 226 98 98 > F 41 61 226 98 97 > > This message is a private communication. If you are > not the intended recipient, please do not read, copy, > or use it, and do not disclose it to others. Please > notify the sender of the delivery error by replying to > this message, and then delete it from your system. > Thank you. The sender does not assume any liability > for timely, trouble-free, complete, virus free, secure, > error free or uninterrupted arrival of this e-mail. For > verification please request a hard copy version. > > -- View this message in context: http://www.nabble.com/problem-retrieving-nodes-from-different-workspaces-tf2177041.html#a6038987 Sent from the Jackrabbit - Dev forum at Nabble.com.
Re: problem retrieving nodes from different workspaces
Were you able to reproduce our problem? Jukka Zitting-3 wrote: > > Hi, > > On 8/28/06, J Kuijpers <[EMAIL PROTECTED]> wrote: >> Supplied repository.xml and runnable MultipleWorkspaceTest.java >> http://www.nabble.com/user-files/235783/repository.xml repository.xml >> http://www.nabble.com/user-files/235784/MultipleWorkspaceTest.java >> MultipleWorkspaceTest.java > > The MultipleWorkspaceTest.java file appears to be empty. Could you > resend it, inline if necessary? > > BR, > > Jukka Zitting > > -- > Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] > Software craftsmanship, JCR consulting, and Java development > > -- View this message in context: http://www.nabble.com/problem-retrieving-nodes-from-different-workspaces-tf2177041.html#a6037018 Sent from the Jackrabbit - Dev forum at Nabble.com.
Re: problem retrieving nodes from different workspaces
ion on errors */ private static Repository getRepository() throws Exception { if (repos == null) { String configFile = "c:/repotest/repository.xml"; String repHomeDir = "c:/repotest"; Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.jackrabbit.core.jndi.provider.DummyInitialContextFactory"); env.put(Context.PROVIDER_URL, "localhost"); InitialContext ctx = new InitialContext(env); RegistryHelper.registerRepository(ctx, "repo", configFile, repHomeDir, true); repos = (Repository) ctx.lookup("repo"); } return repos; } private static void listNodes() { Session session = null; try{ Repository reposNew = getRepository(); session = reposNew.login(new SimpleCredentials("user", "password".toCharArray()), "testWorkspace1"); Query repositoryQuery = session.getWorkspace().getQueryManager().createQuery("testNodes/*", Query.XPATH); QueryResult result = repositoryQuery.execute(); NodeIterator it = result.getNodes(); while (it.hasNext()) { Node node = it.nextNode(); System.out.println(node.getName()); } } catch (Exception e) { e.printStackTrace(); } finally { if (session != null) { session.logout(); } } } } Jukka Zitting-3 wrote: > > Hi, > > On 8/28/06, J Kuijpers <[EMAIL PROTECTED]> wrote: >> Supplied repository.xml and runnable MultipleWorkspaceTest.java >> http://www.nabble.com/user-files/235783/repository.xml repository.xml >> http://www.nabble.com/user-files/235784/MultipleWorkspaceTest.java >> MultipleWorkspaceTest.java > > The MultipleWorkspaceTest.java file appears to be empty. Could you > resend it, inline if necessary? > > BR, > > Jukka Zitting > > -- > Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] > Software craftsmanship, JCR consulting, and Java development > > -- View this message in context: http://www.nabble.com/problem-retrieving-nodes-from-different-workspaces-tf2177041.html#a6019752 Sent from the Jackrabbit - Dev forum at Nabble.com.
problem retrieving nodes from different workspaces
Hello I am having a problem retrieving nodes from different workspaces. I have supplied a runnable example class. In this class I am creating two workspaces and add some nodes to them. When I retrieve the nodes without first shutting down the repository I am getting a result as expected: workspace1Node1 workspace1Node2 workspace1Node3 But when I am shutting down the repository before retrieving the nodes (passing true in the call to runTest(boolean)), I am getting unexpected results: workspace1Node3 This only happens with the DerbyPersistenceManager. Changing to FileSystemPersistenceManager gives no problems. Supplied repository.xml and runnable MultipleWorkspaceTest.java http://www.nabble.com/user-files/235783/repository.xml repository.xml http://www.nabble.com/user-files/235784/MultipleWorkspaceTest.java MultipleWorkspaceTest.java -- View this message in context: http://www.nabble.com/problem-retrieving-nodes-from-different-workspaces-tf2177041.html#a6019261 Sent from the Jackrabbit - Dev forum at Nabble.com.