Community
Participate
Working Groups
Created attachment 86944 [details] duplicate deployment descriptor node Hi, I'm working on an extension to CNF to contribute some content to Dynamic Web Projects. I am noticing that the deployment descriptor node is being rendered twice in the project (see screenshot); may need to close/re-open project to see this. I'll attach a test plugin which exposes this problem. I traced through the code and came across this block of code which seems to be causing some problems: // NavigatorPipelineService.java: ~lines 99-112 for (int i = 0; i < contributions.length; i++) { // returns an array sorted by reverse priority possibleMatches = contentService.findDescriptorsWithPossibleChild (contributions[i]); NavigatorContentDescriptor[] descriptors = (NavigatorContentDescriptor[]) possibleMatches.toArray(new NavigatorContentDescriptor[possibleMatches.size ()]); for (int indx = possibleMatches.size()-1; indx > -1; indx--) { // terminates once the highest priority match is found for this child if(possibleContributors.contains(descriptors[indx])) { contentService.rememberContribution(descriptors[indx], contributions[i]); break; } } } According to the comment, the descriptors array is an array of content providers in reverse priority, highest to lowest (the content provider in my test plugin has lowest priority and I can see it at the end of the array via breakpointing). The for indx loop that comes after looks for the highest priority match but the loop is in reverve direction starting at the end of the array, so I think the code here is picking the lowest priority provider to associate with the contribution (whereas elsewhere in the code the highest priorty provider is picked resulting in a different association).
Created attachment 86945 [details] test plugin exposing this problem
(In reply to comment #0) > Created an attachment (id=86944) [details] > duplicate deployment descriptor node > > Hi, I'm working on an extension to CNF to contribute some content to Dynamic > Web Projects. I am noticing that the deployment descriptor node is being > rendered twice in the project (see screenshot); may need to close/re-open > project to see this. I'll attach a test plugin which exposes this problem. > > I traced through the code and came across this block of code which seems to be > causing some problems: > > // NavigatorPipelineService.java: ~lines 99-112 > for (int i = 0; i < contributions.length; i++) { > // returns an array sorted by reverse priority > possibleMatches = contentService.findDescriptorsWithPossibleChild > (contributions[i]); > NavigatorContentDescriptor[] descriptors = (NavigatorContentDescriptor[]) > possibleMatches.toArray(new NavigatorContentDescriptor[possibleMatches.size > ()]); > for (int indx = possibleMatches.size()-1; indx > -1; indx--) { > // terminates once the highest priority match is found for this child > if(possibleContributors.contains(descriptors[indx])) { > contentService.rememberContribution(descriptors[indx], contributions[i]); > break; > } > } > } > > According to the comment, the descriptors array is an array of content > providers in reverse priority, highest to lowest (the content provider in my > test plugin has lowest priority and I can see it at the end of the array via > breakpointing). The for indx loop that comes after looks for the highest > priority match but the loop is in reverve direction starting at the end of the > array, so I think the code here is picking the lowest priority provider to > associate with the contribution (whereas elsewhere in the code the highest > priorty provider is picked resulting in a different association). > No sure how accurate these comments are, it would seem findDescriptorsByTriggerPoint and findDescriptorsWithPossibleChild should return things in the same order. Need to investigate this further. Can you send the source of your test plugin? I want to see how it might be integrated into the CNF tests.
Hi, sorry it's been a while since I opened this bug, and I don't have the source to the test plugin anymore. However, you can probably decompile the classes to take a look.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
