[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re[2]: [equinox-dev] Location of Persistent UserAdmin Data
|
Ouch!
JM> I have forgotten how the spec works wrt Bundle.getDataFile(). I
JM> vaguely recall that this area is specific to a version (or
JM> generation) of a bundle id. So when you do update, you get a new
JM> area for getDataFile. Is this accurate?
NO!
The data file is associated with the bundle id. As long as the id is
valid, the data file is valid. Updates do not change the id.
Usually, (and wisely) 2.0 should be able to read 1.0 metadata. It
usually has a conversion function that moves the 1.0 data to 2.0
level. Reverting back to an older version is always harder. Friendly
designers however take care of this by not destroying the old data.
Hard part is of course that you never know when you will be updated or
uninstalled.
Kind regards,
Peter Kriens
JM>
JM> This is a very interesting problem. Its not clear that there is
JM> a particular "right answer". For example, you are going from 1.0
JM> to 2.0 (the implication being that it is not backward compatible)
JM> then it *may* be the case that 2.0 cannot read 1.0 metadata. In
JM> that case doing an update vs. uninstall/reinstall would not get
JM> the metadata persistance. Of course, it it might not hurt either
JM> but ... Getting a new services release (e.g., 1.0.1) would seem
JM> to be a good candidate for using update. Interestingly, what
JM> happens when you need to go back to an older version? If the data
JM> written by 1.1 is in a different format than 1.0 there could be issues.
JM>
JM> I have forgotten how the spec works wrt Bundle.getDataFile(). I
JM> vaguely recall that this area is specific to a version (or
JM> generation) of a bundle id. So when you do update, you get a new
JM> area for getDataFile. Is this accurate?
JM>
JM> Jeff
JM>
JM>
JM>
JM>
JM> Thomas Watson <tjwatson@xxxxxxxxxx>
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 06/05/2006 10:02 AM
JM>
JM> Please respond to
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM>
JM>
JM> To
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM> cc
JM>
JM> Subject
JM> Re: [equinox-dev] Location of Persistent UserAdmin Data
JM>
JM>
JM>
JM>
JM> Pascal,
JM>
JM> Can you clarify why Eclispe update can not make these types of
JM> decisions? Take the following example:
JM>
JM> 1) A new feature is installed into Eclipse
JM> 2) As a result update decides to uninstall bundle X version
JM> 1.0.0 and install bundle X version 2.0.0.
JM>
JM> In this case Eclipse update decided it was ok to uninstall
JM> bundle X 1.0.0 and install a new bundle X version 2.0.0. Why
JM> could it not have just updated bundle X version 1.0.0 to bundle X
JM> version 2.0.0 (instead of uninstall/install process)? It had
JM> enough information to decide to uninstall bundle X version 1.0.0
JM> so why not just update it to version 2.0.0? I do not see the issue here.
JM>
JM> Tom.
JM>
JM>
JM>
JM> Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 06/04/2006 04:09 AM
JM>
JM>
JM> Please respond to
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM>
JM>
JM>
JM> To
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM> cc
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
JM> equinox-dev-bounces@xxxxxxxxxxx
JM> Subject
JM> Re: [equinox-dev] Location of Persistent UserAdmin Data
JM>
JM>
JM>
JM>
JM>
JM>
JM> Eclipse update is not in a position of deciding with full
JM> satisfaction of the user whether things should be "updated",
JM> "installed", "uninstalled then installed". For example, if one had
JM> junit 3.8 and wanted to install junit 4.0... what should happen? For that it needs to
JM>
JM> If OSGi was not alwasys tightening up its lose ends with the magic "management agent" :-)
JM>
JM> PaScaL
JM>
JM> Thomas Watson <tjwatson@xxxxxxxxxx>
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 06/01/2006 02:28 PM
JM>
JM>
JM> Please respond to
JM> Equinox development mailing list
JM>
JM>
JM>
JM> To
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM> cc
JM>
JM> Subject
JM> Re: [equinox-dev] Location of Persistent UserAdmin Data
JM>
JM>
JM>
JM>
JM>
JM>
JM>
JM> See bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=73013
JM> against Eclipse->Platform->Update.
JM>
JM> If eclipse update would use the proper Bundle.update method
JM> instead of uninstalling/installing each time a new version of a
JM> bundle bacame available then these types of issues would be solved.
JM>
JM> Tom
JM>
JM> Roy Paterson/Austin/IBM@IBMUS
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 06/01/2006 01:04 PM
JM>
JM>
JM> Please respond to
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM>
JM>
JM>
JM>
JM> To
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM> cc
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
JM> equinox-dev-bounces@xxxxxxxxxxx
JM> Subject
JM> Re: [equinox-dev] Location of Persistent UserAdmin Data
JM>
JM>
JM>
JM>
JM>
JM>
JM>
JM>
JM> BJ's answer is correct from an OSGi spec standpoint, but there are Eclipse
JM> considerations which are relavant to Benjamin's questions. See
JM> http://bugs.eclipse.org/bugs/show_bug.cgi?id=124176#c10.
JM>
JM> In summary bundle ids do not change between framework launches, but if you
JM> update a bundle using Eclipse update it actually uninstalls the old version
JM> and installs the new version, resulting in a new bundle id. This was an
JM> issue with the OSGi Prefs implementation. In the end we just documented it
JM> as a known limitation.
JM>
JM> Regards,
JM> Roy
JM>
JM> -----------------------------------------
JM> Roy Paterson
JM> IBM Pervasive Computing
JM> Austin, TX
JM> Phone: (512) 838-8898
JM>
JM>
JM>
JM>
JM> BJ
JM> Hargrave/Austin/I
JM> BM@IBMUS To
JM> Sent by: Equinox development mailing list
JM> equinox-dev-bounc <equinox-dev@xxxxxxxxxxx>
JM> es@xxxxxxxxxxx cc
JM>
JM> Subject
JM> 06/01/2006 12:20 Re: [equinox-dev] Location of
JM> PM Persistent UserAdmin Data
JM>
JM>
JM> Please respond to
JM> Equinox
JM> development
JM> mailing list
JM> <equinox-dev@ecli
JM> pse.org>
JM>
JM>
JM>
JM>
JM>
JM>
JM> Bundle ids cannot change between framework launches. The bundle id is the
JM> primary key of the bundle and may not change or ever be reused within a
JM> framework instance.
JM>
JM> BJ Hargrave
JM> Senior Technical Staff Member, IBM
JM> OSGi Fellow and CTO of the OSGi Alliance
JM> hargrave@xxxxxxxxxx
JM> Office: +1 407 849 9117 Mobile: +1 386 848 3788
JM>
JM>
JM>
JM> "Benjamin Schmaus" <benjamin.schmaus@xxxxxxxxx>
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 2006-06-01 12:46 PM
JM> Please respond to
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM>
JM>
JM> To
JM> equinox-dev@xxxxxxxxxxx
JM> cc
JM>
JM> Subject
JM> [equinox-dev] Location of Persistent UserAdmin Data
JM>
JM>
JM>
JM>
JM>
JM>
JM> Equinox Developers,
JM>
JM> I've been developing a user/group admin bundle that runs on top of the
JM> Equinox OSGi UserAdmin service implementation, and I've noticed that data
JM> is persisted to a file that is named like so:
JM>
JM> "org.eclipse.core.runtime.preferences.OSGiPreferences." +
JM> bundle.getBundleId()
JM>
JM> So the actual file name might end up being something like:
JM> "org.eclipse.core.runtime.preferences.OSGiPreferences.27.prefs"
JM>
JM> Since a bundle's id can change between framework starts and stops, users
JM> and roles created by a given bundle during one execution of the framework
JM> won't necessarily be available to that bundle in another execution of the
JM> framework ( i.e. since bundle id can vary across runs).
JM>
JM> Should a bundle have to re-create user and role assignments on every start
JM> of the framework if persistent data can't be located? That doesn't seem
JM> right to me.
JM>
JM> It could be that user admin data can be persisted to a static (known
JM> before runtime) location via the Equinox UserAdmin impl, but it's not
JM> clear to me how this should be done.
JM>
JM> - Ben Schmaus_______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM>
JM>
JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM>
JM>
JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM>
JM>
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
