Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 449765

Summary:	Framework should provide a persistent UUID
Product:	[Eclipse Project] Equinox	Reporter:	Cristiano Gaviao <cvgaviao>
Component:	Framework	Assignee:	Thomas Watson <tjwatson>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	david_williams, pascal, sptaszkiewicz, tjwatson, wayne.beaton
Version:	unspecified	Keywords:	helpwanted
Target Milestone:	---
Hardware:	PC
OS:	Linux
See Also:	https://git.eclipse.org/r/70783 https://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=3841a41167128ab80ffe8f05bf793694f5c28400 https://git.eclipse.org/r/75405 https://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=e234ae5142ed330df84a5eae361f864aa5cb0c10
Whiteboard:

Description Cristiano Gaviao

2014-11-03 08:22:23 EST

Currently, as specified by the spec, one different universally unique identifier (UUID) are generated every time a new Framework instance is initialized and this value is registered as a property of the Framework object (org.osgi.framework.Constants.FRAMEWORK_UUID).

That is ok for almost all situations, but it is not in a cloud network scenario because it makes difficult to have a central table of installed OSGi containers/nodes and configure them from an unique place.

The proposal is the framework to generate one UUID for its persistent storage or something like that. 
it would keep the generation of the UUID for each instance but maybe associate those with a timestamp and the fixed UUID.

Comment 1 Thomas Watson

2014-11-04 17:09:41 EST

If I were to do this I would start at org.eclipse.osgi.internal.framework.EquinoxBundle.SystemBundle.EquinoxSystemModule.initWorker()

That is where the framework UUID is set.  I would probably augment org.eclipse.osgi.internal.framework.UniversalUniqueIdentifier to have another constructor that took a string to the path of the framework storage area.  This UUID would base its value off the nodeAddress and the framework storage area instead of the timeValues + nodeAddress.

Comment 2 Szymon Ptaszkiewicz

2015-07-17 07:51:28 EDT

(In reply to Cristiano Gaviao from comment #0)
> That is ok for almost all situations, but it is not in a cloud network
> scenario because it makes difficult to have a central table of installed
> OSGi containers/nodes and configure them from an unique place.

I tried to implement this as suggested in comment 1, but before I spend too much time on that can you please explain where this difficulty comes from? Thanks!

Comment 3 Eclipse Genie

2016-04-15 14:40:59 EDT

New Gerrit change created: https://git.eclipse.org/r/70783

Comment 4 Thomas Watson

2016-04-20 14:55:47 EDT

(In reply to Eclipse Genie from comment #3)
> New Gerrit change created: https://git.eclipse.org/r/70783

I put an implementation of this in that gerrit review.  It basically changes the UUID generation to use the UUID class of the VM instead of the internal one in Equinox.

I decided to go with version 4 type UUID.  Before we were using a variant of version 1 which I think has shown to have some security concerns.  For the persistent UUID I store the value in the property "org.eclipse.equinox.persistent.uuid".  This value is generated on first init from a clean storage area and is persistently used each restart of the framework that uses the same storage area.  If the framework is launched with -clean then a new persistent UUID will get generated.

Pascal, does this help you out in your p2 needs?  If so we can try to get this into Neon.  Cristiano, does would this help your usecase?

Comment 5 Thomas Watson

2016-04-22 11:49:42 EDT

Will not add to Neon at this point.  Will add in Oxygen.  I don't think the persistent storage UUID will help with Pascals needs based on discussions I have had with Pascal.

Comment 6 Eclipse Genie

2016-06-15 12:21:08 EDT

Gerrit change https://git.eclipse.org/r/70783 was merged to [master].
Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=3841a41167128ab80ffe8f05bf793694f5c28400

Comment 7 Eclipse Genie

2016-06-16 10:33:48 EDT

New Gerrit change created: https://git.eclipse.org/r/75405

Comment 8 Eclipse Genie

2016-06-16 10:35:15 EDT

Gerrit change https://git.eclipse.org/r/75405 was merged to [master].
Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=e234ae5142ed330df84a5eae361f864aa5cb0c10

Comment 9 Thomas Watson

2016-06-16 10:54:48 EDT

Given the concerns over p2's usage of a UUID at the end of Neon we have decided to remove this enhancement until a proper discussion is made concerning UUIDs with the Eclipse Foundation and the community.

My opinion is that the UUID being proposed here does not have the same concerns as the UUID p2 was proposing at the end of Neon (bug 495484).

OSGi already has a UUID specified [1].  This UUID identifies a running instance of the OSGi framework but is regenerated each time the framework is restarted.  The UUID being proposed in this enhancement would identify a persistent installation of the framework.  If the identity of the running instance of the framework is not a concern then I don't see why the identity of a framework installation instance would be a concern.  In both cases the UUIDs produced by the framework are only accessible internally to the framework and the bundles installed.  The framework never sends such data to third parties.  An additional enhancement would have to be added to do that (similar to the one p2 was adding with bug 490112).


[1] https://osgi.org/javadoc/r6/core/org/osgi/framework/Constants.html#FRAMEWORK_UUID

Comment 10 Thomas Watson

2016-08-10 10:34:43 EDT

No plans to do this enhancement at this point.