How to remove an old version from VersionHistory?

[simone.l]

I've a structure of [nt:folder] and [nt:file] nodes.

[nt:file] have the versionable mixin and an additional mixin used to store custom metadata.

I've to implement the requirement to allow editing the custom metadata on the last file version.

If this could be possibile my problem could be really close to the solution but I've not found a way to do this. Can someone confirm if is possibile or not?

The idea to solve the problem is to:

- Add a new version

- Delete the previous one

So i've added the new file version ending the add-section with this line:

          Version newFileVersion = versionManager.checkin(path);

After that I've tryed to delete the previous version with this code:

            Version previousVersion = newFileVersion.getPredecessors()[0];

            VersionHistory versionHistory = versionManager.getVersionHistory(path);

            VersionIterator versionIterator = versionHistory.getAllLinearVersions();

            while (versionIterator.hasNext()) {

                Version version = versionIterator.nextVersion();

                if (version.getIdentifier().equals(previousVersion.getIdentifier())) {

                    versionHistory.removeVersion(version.getName());

                    break;

                }

            }

The code runs without throwing exception but the history node was not cancelled.

What's wrong?

What's the best practice to remove an older version of a node?

Thanks,

Simone

[rhauch]

That's the correct way to remove individual versions from the history, and functionality should work. Which version of ModeShape are you using?

[simone.l]

I've tryed both 2.8.2.Final and 2.8.3.Final but i need the last one.

If could be usefull, you can find my configuration here:

https://community.jboss.org/message/753380#753380

After versionHistory.removeVersion(version.getName()); i do nothing except a logout.

Should i call session.save() or something else? For what I've understood the answer should be no. Am I right?

[rhauch]

I've tryed both 2.8.2.Final and 2.8.3.Final but i need the last one.

You could try it, but 2.8.4.Final contains no changes to version management and therefore I would expect the same (incorrect) behavior.

The reason I ask is that the versioning code in 3.0 is quite different from 2.x, and I just wanted to be sure I'm helping by looking at the same codebase you're using.

After versionHistory.removeVersion(version.getName()); i do nothing except a logout.

Should i call session.save() or something else? For what I've understood the answer should be no. Am I right?

It should not be necessary to call "session.save()", since all VersionManager-related calls are performed immediately. However, how do you know that the specific version hasn't been removed? If you're using a Session, I'd try using a new Session to check the history. (It shouldn't matter, but it might help us diagnose what's going wrong.)

[simone.l]

2.8.4? Pheraps is a typo? I see as last downloadable release 2.8.3.Final that is the one I'm currently using.

I've created a web service and I've, for this case, 3 web methods of interest and of course, each of them use a new session.

- AttachmentAdd (create a nt:file)

- AttachmentEdit (do what described above: checking in a new version, deleting the previous version)

- AttachmentHistory (list all nt:file version nodes)

Sequence of invocation:

- AttachmentAdd

- AttachmentHistory (1 entry)

- AttachmentEdit

- AttachmentHistory (2 entries but if the AttachmentEdit method had worked it should be just one)

[rhauch]

2.8.4? Pheraps is a typo? I see as last downloadable release 2.8.3.Final that is the one I'm currently using.

Yes, you're right. Apologies.

I've created a web service and I've, for this case, 3 web methods of interest and of course, each of them use a new session.

- AttachmentAdd (create a nt:file)

- AttachmentEdit (do what described above: checking in a new version, deleting the previous version)

- AttachmentHistory (list all nt:file version nodes)

Sequence of invocation:

- AttachmentAdd

- AttachmentHistory (1 entry)

- AttachmentEdit

- AttachmentHistory (2 entries but if the AttachmentEdit method had worked it should be just one)

If you haven't already, can you log an issue against 2.8.3.Final? As I said, it should work.

[simone.l]

I've created the issue as you have requested:

https://issues.jboss.org/browse/MODE-1624

To be totally sure that is not a problem of my code, I've tryed to use the InMemory store but it doesn't work too. I've also tryed the filesystem provider but it doesn't work because I'm using a nt:unstructured node inside my custom mixin that the provider seem to be not able to manage.

I've also tryed to use JackRabbit as other JCR implementation and in this case it works.

Hope this info could be usefull for your investigations.

I kindly ask, if will be confirmed as a bug, to estimate a release date for the 2.8.4.Final version.

Thanks,

Simone

[rhauch]

Thanks for logging the issue and reporting this. I think you've provided enough information for us to debug and fix it. Plus, we will try to fix it be 2.8.4.Final and make sure it works in 3.0.

[simone.l]

What about release 2.8.4?

I've seen modeshape 3.x is released but:

- I cannot switch to JBOSS 7

- Any support is provided to run it on JBOSS 5

- I need to store data on SQL Server and Oracle databases

For these reasons I cannot move now to the last version because there is a really huge impact on the project i'm working on.

Thanks,

Simone

PS = The lack of support for JBOSS 5 is really a glitch; in order to update MODESHAPE, in some way you are forced to change your application server and it's a bit too much :-(

[rhauch]

What about release 2.8.4?

It will be coming within the next month.

I've seen modeshape 3.x is released but:

- I cannot switch to JBOSS 7

- Any support is provided to run it on JBOSS 5

Understood. But you can always embed 3.0 into your web application. And we've recently added a JCA adapter in what will become 3.1. It'd be great if you have time to build 'master' locally and check it out to see if it works with JBoss 5 and is suitable for you. There's still time to incorporate any feedback, suggestions or fixes before the 3.1 release.

- I need to store data on SQL Server and Oracle databases

You can still do this with ModeShape 3, just using one of Infinispan's two JDBC cache stores.

[simone.l]

I've tried to embed it inside my EAR but infinispan doesnt work.

I've also found this article that describes how to run infinispan under JBOSS 5

https://docs.jboss.org/author/display/ISPN/Infinispan+as+Hibernate+2nd-Level+Cache+in+JBoss+AS+5.x

but this cause some problem to the application; in order to try this I should refactor a bit the application creating a separated and isolated EAR just to contain Modeshape and Infinispan.

Oracle and Sql Server are officially supported / tested by the JDBC cache stores?

I've a question about scale out.

We need only to add application servers with a load balancer and the application servers don't need to know each other.

What about modeshape 3 with inifinispan? I suppose it's needed to cluster the 2+ cache or is possibile, having only one db store, to keep nodes unknow to each other?

When 3.1 relase is planned? The JCA adapter will be tested also on JBOSS 5?

As a suggestion I think that all the users that works on JBOSS 5 with Modeshape 2 will appreciate that JBOSS 5 continues to be supported. I was really satisfied by the copy and paste installation of the previous version.

Our application should run also over web sphere and web logic; support for these application servers will be great too.

Simone

[rhauch]

Oracle and Sql Server are officially supported / tested by the JDBC cache stores?

Community doesn't "officially support" anything really. The code appears to support lots of DBMSes, but it's hard to tell from the codebase where their integration tests are.

I've a question about scale out.

We need only to add application servers with a load balancer and the application servers don't need to know each other.

What about modeshape 3 with inifinispan? I suppose it's needed to cluster the 2+ cache or is possibile, having only one db store, to keep nodes unknow to each other?

Really you need to cluster the ModeShape instances together - this was true in ModeShape 2.x and remains true in 3.x. The reason is that an event fired in one process needs to be visible to the other processes, not just for listeners but also for indexing. In 2.x, that was the only communication that occurred between cluster processes. In 3.x, this is a bit different because Infinispan cache that we use for storage should also be clustered to get the benefit of replication or distribution. But 3.x is elastic in the sense that at any time you can easily add new processes to the cluster and remove processes from the cluster.

When 3.1 relase is planned? The JCA adapter will be tested also on JBOSS 5?

With the holidays, 3.1 will almost certainly slip to the first few weeks in January. I don't think we've yet tested the JCA adapter on JBoss AS5. Any help here would be appreciated, though!

As a suggestion I think that all the users that works on JBOSS 5 with Modeshape 2 will appreciate that JBOSS 5 continues to be supported. I was really satisfied by the copy and paste installation of the previous version.

Migrating the older AS5 subsystem was too much work for us, but we'd welcome contributions. The JCA adapter should help in this situation, too.

Our application should run also over web sphere and web logic; support for these application servers will be great too.

Again, this is why we added the JCA adapter.

[simone.l]

Can you please confirm if the bug about version history is or will be fixed in the 2.8.4 release?

[rhauch]

At this point, it is scheduled to be fixed before 2.8.4. The only reason it wouldn't be included is if (for some bizarre reason) we can't fix it - but I can't even imagine that's the case.