[eclipse.org-architecture-council] [Bug 246840] [discussion] How to use

[bugzilla-daemon@xxxxxxxxxxx]

https://bugs.eclipse.org/bugs/show_bug.cgi?id=246840  
Product/Component: Platform / Runtime




--- Comment #2 from Markus Schorn <markus.schorn@xxxxxxxxxxxxx>  2008-09-15 05:39:12 -0400 ---
(In reply to comment #1)
Your description of how isConflicting() should be implemented is what my
intuition also tells me, however it is not documented like this in
ISchedulingRule. Your interpretation implies that I cannot write a rule that
has a relationship to a rule that I don't have control over (e.g. IResource),
whereas the documented API allows for writing a rule that 'contains' an
IResource but does not 'conflict' with it. From the documentation it is unclear
what consequences such a rule would have. I think it should not be allowed to
do that, because it essentally allows to bypass a lock.

I understand why rule factories were introduced. However this consturction
leads to a significant problem in practice. The main issue in short is that
whenever I use API in jobs with my own scheduling rules I cannot be sure that I
don't run into the IllegalArgumentException. I would have to check the
implementation of the API I am calling and even then I don't know whether the
implementation will be kept the same in a future version.


Here is an example:
1) When innocently using org.osgi.service.prefs.Preferences.flush() in a job
with a scheduling rule of mine I made the mistake not to know that calling this
method potentially acquires a lock on resources (this is the case when dealing
with project-preferences). 

2) As a fix I need to find out (by looking into the implementation of flush()) 
   what rules to obtain:
                                rf.modifyRule(preferenceFile), 
                                rf.createRule(preferenceFile.getParent()),
                                rf.createRule(preferenceFile), 
                                rf.deleteRule(preferenceFile) 

3) There is no API by which I can determine the file used to store the 
   preferences. I need to duplicate this code.

4) There is no guarantee that the rules used within flush() will stay the same 
   in a future version.

5) Even when using the rule-factory, the solution is not 100% reliable, because
   the rule-factory obtained via
ResourcesPlugin.getWorkspace().getRuleFactory()
   can be different depending on when it is called, so that the rules obtained
   when creating the job are differnet to the rules obtained when actually 
   running the job. I did not make this up: bug 240888

==> The consequence for me was to use the IWorkspace rule instead, which is a
reasonable solution. However, the problem had to be discovered by a user first,
which is the greatest overall issue.


-- 
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.