Remote component search messes up returns which have the same karFileName in kar xml
On 2010-09-01, Jones uploaded the kar xml 2099.22.1 and kar file 2099.21.1. In the kar xml, it says the kar file (2099.21.1) NOT having a report module. We looked the kar file, it is true that it doesn't have a report module.
On 2010-10-27, Jones uploaded the kar xml 3075.20. 1 and kar file 2099.21.2. In the kar xml, it says the kar file (2099.21.2) having a report module. We looked the kar file, it is true that it dose have a report module.
Both kar xml have the same karFileName - BoxPlotDemo.kar
However, when we searched the remote repository, it seems there is only one workflow with the name BoxPlotDemo.kar showing - 3075.20.1 with the report. Something is messed up.
I looked the log and saw both "Parsing KAR XML: 2099.22.1" and "Parsing KAR XML: 3075.20.1". This means that metacat's return is good. But kepler component search has a bug. The worse case is that the component search messes up the kar id - it assigns 2099.21.1 which doesn't have a report to kar xml 3075.20. 1. So our workflow run engine downloaded a wrong kar file and executed it. Since the kar file doesn't have a report, there will not be workflow run kar being uploaded to the remote server.
Updated by Jing Tao over 13 years ago
I dug around and found in method EcogridRepositoryLibrary.createKarLevel():
it used the kar file name as the entity name to create an entity. When a NameDuplicationException was genenrated, the previous entity will be removed.
So I modified the code to add an appendix to the name - karid and karxml file id if a NameDuplicationException is generated.
This method was called during processing every karEntries. This is not good, we only need to call it once during generating kar file level (karXML). So I fixed it.