Community
Participate
Working Groups
We have a case where the osgi.framework property in the config.ini is written both in the shared config area as well as the user's local config area. Both values are file: URLs but the problem seems to be that the property value in the shared location is an absolute path whereas the value in the user area is relative. So later on when we try and figure out what key/value pairs we want to remove from the user's copy because they are the same as the shared values, we don't pick this up as being the same so the key/value pair remains. There are a couple of options here: 1). Check to see if we have the osgi.framework key (make it something that we know about specially... we do this for a couple of others) and if we do, then canonicalize the URLs before comparing them. 2). It can be argued that the osgi.framework property should never be written to the user's local copy of the config.ini. If it is and if the shared install is updated to use a new copy of the framework, then the new install will not work. We need to figure out how this fits into our product upgrade scenario for shared installs. Relavent code is in EquinoxFwConfigFileParser#filterPropertiesFromSharedArea
Created attachment 182777 [details] initial patch Initial patch which recognizes the osgi.framework property, makes both the shared and user locations absolutes URIs, and then does the comparison.
Normally, fwkadmin should *always* deal in absolute URIs. That is, when it reads from disk, relative URIs should be made absolute, and any URI set by through the API should be absolute. The fact that you have to make it absolute on save is kind of weird to me. Did you check how we end up with a relative URI at this stage?
(In reply to comment #0) > 2). It can be argued that the osgi.framework property should never be written > to the user's local copy of the config.ini. If it is and if the shared install > is updated to use a new copy of the framework, then the new install will not > work. If I understand correctly, if we *ever* write the osgi.framework property in the user's private config.ini, then we will never be able to upgrade the framework again for that install (because we have special code that detects this case in ConfigApplier and bails out). If this understand is correct, I think we should just never write the osg.framework property in the user's local config.ini in a shared install.
*** Bug 326682 has been marked as a duplicate of this bug. ***
Created attachment 183000 [details] patch Patch which removes the osgi.framework property from the user's local config.ini.
Tom: what are your thoughts about changing the code in the launcher so we never read the osgi.framework property from the user's config.ini file? The current patch never writes it so adding code to never read it might help us with migration problems for users who currently have a value written locally but the shared content has been updated.
(In reply to comment #2) > Normally, fwkadmin should *always* deal in absolute URIs. That is, when it > reads from disk, relative URIs should be made absolute, and any URI set by > through the API should be absolute. > > The fact that you have to make it absolute on save is kind of weird to me. Did > you check how we end up with a relative URI at this stage? I have confirmed that it is the product's installer which writes out the osgi.framework property as an absolute URL and verified that the p2 code does the right thing and tries to make things relative.
(In reply to comment #6) > Tom: what are your thoughts about changing the code in the launcher so we never > read the osgi.framework property from the user's config.ini file? The current > patch never writes it so adding code to never read it might help us with > migration problems for users who currently have a value written locally but the > shared content has been updated. I missed this question, sorry. If you never want the osgi.framework property to be read from the users config.ini then you could set the property (as a VM -D arg) in the eclipse.ini instead of the config.ini. -D VM property settings take priority over any options set in the config.ini files.
*** Bug 336176 has been marked as a duplicate of this bug. ***
Patch released. We no longer write out the osgi.framework property in the user's config.ini file in the shared install case. (comment 3) The product originally reporting this bug has been able to work around their problem by using the mechanism specified in bug 330133. Closing.
