Bugzilla – Full Text Bug Listing
| Summary: | Support framework UUID | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Thomas Watson <tjwatson> | ||||
| Component: | Framework | Assignee: | Thomas Watson <tjwatson> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | hargrave, slewis | ||||
| Version: | 3.7 | ||||||
| Target Milestone: | 3.7 M4 | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Thomas Watson
Created attachment 181105 [details]
Patch + test
Here is a patch and test. More tests should be done to verify the string is a valid UUID. To do that we need to update to using java 5 for the tests.
Patch released. Leaving open to added tests that use java.util.UUID to verify the UUID is correctly formatted. . I released an additional test to verify the format of the UUID. Hi Thomas. A quick question about org.osgi.framework.uuid, as I am using it in the implementation of OSGi 4.2 remote services admin (it's one of the required EndpointDescription properties). What does support for this mean? Does a given framework set a persistent uuid value on first invocation (if it's not set)...or something like that...i.e. when is the uuid property created/set? Does it persist across invocations of a given framework, or is it reset (if not explicitly set as a system property, I assume) upon every framework start...or ? Thanks. (In reply to comment #5) > Hi Thomas. > > A quick question about org.osgi.framework.uuid, as I am using it in the > implementation of OSGi 4.2 remote services admin (it's one of the required > EndpointDescription properties). > > What does support for this mean? Does a given framework set a persistent uuid > value on first invocation (if it's not set)...or something like that...i.e. > when is the uuid property created/set? Does it persist across invocations of a > given framework, or is it reset (if not explicitly set as a system property, I > assume) upon every framework start...or ? > > Thanks. The framework UUID uniquely identifies a running instance of a framework. This is not a persistent ID. Each time the framework is initialized (e.g. each time eclipse is restarted) a new UUID is generated by the framework for the new running instance. The framework ignores a configuration setting of the org.osgi.framework.uuid property and will always generate a new one each time the framework is initialized. (In reply to comment #6) <stuff deleted> > > The framework UUID uniquely identifies a running instance of a framework. This > is not a persistent ID. Each time the framework is initialized (e.g. each time > eclipse is restarted) a new UUID is generated by the framework for the new > running instance. The framework ignores a configuration setting of the > org.osgi.framework.uuid property and will always generate a new one each time > the framework is initialized. Is it possible to have/set the framework UUID to the same value persistently (across framework starts/stops)? Or is it (by spec?) always a different/unique value on framework restarts? (In reply to comment #7) > (In reply to comment #6) > <stuff deleted> > > > > The framework UUID uniquely identifies a running instance of a framework. This > > is not a persistent ID. Each time the framework is initialized (e.g. each time > > eclipse is restarted) a new UUID is generated by the framework for the new > > running instance. The framework ignores a configuration setting of the > > org.osgi.framework.uuid property and will always generate a new one each time > > the framework is initialized. > > Is it possible to have/set the framework UUID to the same value persistently > (across framework starts/stops)? Or is it (by spec?) always a different/unique > value on framework restarts? This is spec'ed behavior. My understanding is that the UUID is supposed to be useful for remote services. Your comments make it sound like it is not going to be helpful? Each instance session of the framework is considered unique and is required to have a different UUID. (In reply to comment #8) > (In reply to comment #7) > This is spec'ed behavior. My understanding is that the UUID is supposed to be > useful for remote services. Your comments make it sound like it is not going > to be helpful? Each instance session of the framework is considered unique and > is required to have a different UUID. Yes. The UUID represents a specific running framework instance. You can't reuse the UUIDs across instances. This allows an endpoint to specifically point to a specific running framework instance. (In reply to comment #6) <stuff deleted> > > This is spec'ed behavior. My understanding is that the UUID is supposed to be > useful for remote services. Your comments make it sound like it is not going > to be helpful? Each instance session of the framework is considered unique and > is required to have a different UUID. Ok. In answer to your question about being helpful...I am indeed in the middle of implementing the OSGi remote services admin spec, and the framework id plays a role in that (it's considered required meta-data for discoverying a remote endpoint...described by an EndpointDescription object (which requires a RemoteConstants.ENDPOINT_FRAMEWORK_UUID to be set). My query about the persistence (or even optional persistence) of the framework uuid is based upon an expectation that there are remote service use cases where a persistent framework uuid would be desirable...e.g. having a xml-file-based EndpointDescription (with a framework uuid) that isn't obsolete/doesn't have to be updated every time the remote framework restarts. I guess since framework uuid (as currently spec'd) is always recreated/reset upon restart, the framework uuid wouldn't support these use cases (i.e. service.pid can/could include such information I suppose). That is...*any* previously created EndpointDescription (whether conveyed via file, network, or whatever) would be obsolete when the framework stops and is then restarted. There are other ways to represent a persistent framework identifier (e.g. it could be part of service.pid), but I was thinking of the remote service consumers that (e.g.) use the framework uuid. Thanks to both for the answer. If you think I'm missing something please let me know. |