Bug 180080 - Equinox Application Admin spec violations
Summary: Equinox Application Admin spec violations
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Compendium (show other bugs)
Version: 3.3   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.3 M7   Edit
Assignee: Thomas Watson CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks:
 
Reported: 2007-03-29 17:03 EDT by Josh Arnold CLA
Modified: 2007-04-11 16:40 EDT (History)
1 user (show)

See Also:


Attachments
Suggested patch (2.62 KB, patch)
2007-03-29 17:30 EDT, Josh Arnold CLA
no flags Details | Diff
patch (13.41 KB, patch)
2007-04-05 15:41 EDT, Thomas Watson CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Josh Arnold CLA 2007-03-29 17:03:33 EDT
Build ID: I20070209-1006

Steps To Reproduce:
There are a few places where the new Equinox Application Admin service does not comply with the OSGi Mobile Specification (Release 4.0).

1. Incorrect format for ApplicationHandle instance ids.

Section 116.7.5.6 of the mobile spec states that instance ids should be of the form <application_descriptor_PID>.<index>.  Furthermore, it goes on to state that the index value should not be reused in a reasonably long time frame.  The implication is that consumers can safely use the instance id (= ApplicationHandle PID) to determine if the application instance is still running.

For "singleton" applications, EclipseAppDescriptor.getInstanceID() just use ApplicationDescriptor PID as the instance id.  Not only is the format incorrect, but consumers can no longer distinguish between one instance and a subsequent instance of  a singleton app.

For other applications, EclipseAppDescriptor.getInstanceID() sets the instance id to <application_descriptor_PID>_<index>, which is functionally OK, but it differs from the suggested format in the spec.

2. ApplicationHandle service should release its locks before unregistering.

Section 116.3.2 of the mobile spec states that any rsesources used by the application (including locks) should be cleaned be up before the service is unregistered.  However, EclipseAppHandle.setAppStatus() unregisters the service before releasing its cardinality/thread locks.  

For example, if I use a ServiceTracker to detect that a "scoped" application instance has been unregistered.  I should be able to immediately start a new "scoped" application.  Currently, I don't think I can do this without introducing a race condition.

3. Custom ApplicationHandle states should use a qualified name.

This is a minor, but 116.2.4 of the mobile spec states that container-specific states should use qualified (dotted) names.  The EclipseAppHandle defines "starting" and "stopped" which are not part of the 4.0 spec.  Perhaps these are becoming standard, but if they are not then they should probably use qualified names.



More information:
Comment 1 Josh Arnold CLA 2007-03-29 17:30:43 EDT
Created attachment 62434 [details]
Suggested patch
Comment 2 Thomas Watson CLA 2007-03-30 08:58:54 EDT
Thanks, I will take a look for M7.
Comment 3 Thomas Watson CLA 2007-04-05 15:41:31 EDT
Created attachment 63095 [details]
patch

I used your solution for the fixes to EclipseAppHandle.  You are right that we should release the application lock before unregistering the service.  We should also use qualified names for starting and stopped.

I used a different solution for the instance ids.  I did not like the global instance id that we had in the first place.  The instance id counter should really be for each ApplicationDescriptor and not a global counter.  I also put a check incase we hit overflow the long (not likely to happen but ...)
Comment 4 Thomas Watson CLA 2007-04-05 15:44:40 EDT
I released the patch.  Josh I added your name to the copyright of EclipseAppHandle.  Let me know if you do not want your name here, perhaps you would rather your employer?
Comment 5 Josh Arnold CLA 2007-04-11 16:40:53 EDT
Sorry for the late reply - the copywrite is fine.

Thanks