Bug 105450 - [osgi] condpermadmin must allow recursion check for different condition types
Summary: [osgi] condpermadmin must allow recursion check for different condition types
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Runtime (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.1.1   Edit
Assignee: Thomas Watson CLA Friend
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-28 10:52 EDT by Thomas Watson CLA Friend
Modified: 2005-08-04 19:10 EDT (History)
1 user (show)

See Also:


Attachments
Proposed fix (6.13 KB, patch)
2005-07-28 17:25 EDT, Thomas Watson CLA Friend
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Watson CLA Friend 2005-07-28 10:52:04 EDT
According to the OSGi R4 specification ...

"The same Condition object must not be evaluated recursively. The
Framework must detect the recursive evaluation of a Condition object and
pretend that the second invocation returns an unsatisfied not postponed
Condition object."

This is to prevent postponed condition checks from looping into an endless 
recursion.  The current implementation prevents any type of recursion, even if 
the recursion does not go into the same condition class more than once.  
Recursion should be allowed as long as we can detect that the same condition 
class is not used more than once in a recursive check.
Comment 1 Thomas Watson CLA Friend 2005-07-28 11:27:35 EDT
Fixed in HEAD for 3.2.  Still need to backport to 3.1.1.
Comment 2 Thomas Watson CLA Friend 2005-07-28 11:36:37 EDT
Leaving bug open to backport fix to 3.1.1
Comment 3 Thomas Watson CLA Friend 2005-07-28 17:25:41 EDT
Created attachment 25439 [details]
Proposed fix
Comment 4 Thomas Watson CLA Friend 2005-07-28 17:53:19 EDT
Pascal, please review patch against 3_1_maintenance branch.
Comment 5 Pascal Rapicault CLA Friend 2005-08-04 18:37:55 EDT
Tom explained me the core of the patch and it is good to go.
This code is however a good place for 3.2 optimizations (not because of the
patch itself but because of its shape).
Comment 6 Thomas Watson CLA Friend 2005-08-04 19:10:23 EDT
Fixed in R3_1_maintenance branch.