[MAGNOLIA-2704] activation: support activation of same name siblings Created: 21/Apr/09  Updated: 28/Feb/14  Resolved: 28/Feb/14

Status: Closed
Project: Magnolia
Component/s: activation
Affects Version/s: 4.0.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Manfred Stock Assignee: Daniel Lipp
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OpenJDK 1.6.0 on CentOS 5.3 64bit with ext3 filesystem, Magnolia OnAir 4.0.1


Attachments: XML File author-data.rtsi.proxyObjects.2009.04.02.Test-05.xml     XML File public-data.rtsi.proxyObjects.2009.04.02.Test-05.xml    
Issue Links:
relation
is related to MAGNOLIA-2771 activation: children are activated be... Closed
is related to MAGNOLIA-5433 As a developer it's clear that I cann... Closed
is related to MAGNOLIA-2738 Duplicate content and activation prob... Closed
is related to MGNLACTIVATION-67 Same name siblings Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

In situation where it is possible that two same name siblings exist, during activation of these nodes, the MetaData nodes get mixed up between the two nodes (i.e. it seems that the 'first' node gets the content of the 'second' node's MetaData node).

It is possible to reproduce this by importing the attached author-data.rtsi.proxyObjects.2009.04.02.Test-05.xml into the data workspace, and then trying to activate it. The data in the author instance will be ok, but the data in the public instance will be mixed up, about as in the above example.



 Comments   
Comment by Philipp Bärfuss [ 23/Apr/09 ]

Magnolia does not support same name siblings. You are not able to create such nodes in the tree for instance. That is something you can bypass by using jcr API or import but you shouldn't.

The main question is wether you need same name siblings support (if so we would have to see if we can fix related issues) or if you can ensure that the names are unique. Without having serious reasons I would not like to start working on that topic.

Is this OK for you?

Comment by Manfred Stock [ 23/Apr/09 ]

Partially . I was not aware that this is not supported, so we never cared about it, as it does work in the author instance - it's only the activation which does not work correctly. I think we should be able to work around it on our side, but this would require an additional query using the info.magnolia.module.onair.filters.MBInterfaceListener interface each time we create/rename a proxy object (in order to check if there already is an object with the same name). I would like to avoid this because of performance considerations (in the case where I create several proxy objects) and because it might not be that robust (concurrent accesses).

As 'same name siblings support' does not seem to be that trivial, my preferred solution would be an extension of the info.magnolia.module.onair.filters.ArteriaListener such that it adapts the node name in create/rename operations if necessary. That would make it easier for me , and moves the responsibility closer to Magnolia, which should make it more robust, especially in the case where concurrent accesses happen. The inherent problem with touching this class is that RSI has some older version of it installed (i.e. they don't have OnAir...) which dates to sometime before any cleanup/merging took place. So we'll have to find some way to update the enclosing module in their installation...

Comment by Philipp Bärfuss [ 24/Apr/09 ]

How urgent is that? We might want to check if we could fix the activation issue. It might be the better solution as it prevents us from similar issues in the future.

Comment by Philipp Bärfuss [ 24/Apr/09 ]

Hi Jan,

Can you check if we could fix that?

Comment by Manfred Stock [ 24/Apr/09 ]

Hard to say. I don't think that it is really urgent, as RSI has left the priority of the original ticket on 'normal' so far, and they usually increase the priority if they consider something as important. If a fix for the activation issue takes a little longer, I could still implement a simple workaround for the most common case where RSI encountered the problem. And I'd definitely prefer a fix for the underlying issue if this is possible.

Comment by Jan Haderka [ 28/Apr/09 ]

This is an activation issue. Updated and shortened description to make it easier to read.

Comment by Jan Haderka [ 28/Apr/09 ]

Fixed as of r24544 on trunk, r24545 on 4.0 branch and as of r24546 on 3.6 branch.

Comment by Philipp Bärfuss [ 09/Jun/09 ]

I am reopening the issue because this has unwanted side effects. For now (4.1) magnolia activation will just not support activation of same name siblings. Magnolia as such is dependent on having unique names (urls, ..) in several places.

Following I list some scenarios which brought me to that decision. In all this situation the logical same path on author and public actually have a different uuid and would become same name siblings after an activation while a user expects that an activation leads to overwriting that node.

1) installation task / update tasks

  • creates a node structure and the nodes get the uuid just in time

2) STK: templates, resources, images in dms

  • the are installed by tasks but not by bootstrap files
  • same path has different uuid on author and public

3) root node of data types in the data module

  • they are also created and not bootstrapped

4) import of data (not jcr import)

  • like fetching products from a service and adding them to the data module
Comment by Philipp Bärfuss [ 09/Jun/09 ]

Here are some ideas to be considered while finding a solution:

A) make the behaviour configurable per workspace

B) if the node is not a sibling in source instance it wont be one in the destination

Personally I prefer B)

Comment by Jan Haderka [ 12/Jun/09 ]

Unfortunately solution for this issue have been conflicting with solution for MAGNOLIA-2771 which was a blocker for release 4.1. Solution to this issue (while keeping changes necessary for MAGNOLIA-2771) will be revisited after the release.

Generated at Mon Feb 12 03:39:17 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.