[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: |
|
||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||
| 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 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 |
| 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
2) STK: templates, resources, images in dms
3) root node of data types in the data module
4) import of data (not jcr import)
|
| 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 |