Re: [equinox-dev] [prov] install / uninstall / update (was Configuration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]

Re: [equinox-dev] [prov] install / uninstall / update (was Configuration Admin bug)

From: James D Miles <jdmiles@xxxxxxxxxx>
Date: Mon, 10 Dec 2007 17:22:52 -0600
Delivered-to: equinox-dev@xxxxxxxxxxx
List-archive: <https://dev.eclipse.org/mailman/listinfo/equinox-dev>
List-help: <mailto:equinox-dev-request@eclipse.org?subject=help>
List-subscribe: <https://dev.eclipse.org/mailman/listinfo/equinox-dev>, <mailto:equinox-dev-request@eclipse.org?subject=subscribe>
List-unsubscribe: <https://dev.eclipse.org/mailman/listinfo/equinox-dev>, <mailto:equinox-dev-request@eclipse.org?subject=unsubscribe>

In the old eclipse we would have allowed only one bundle version to be enabled for a user. Multiple versions could exists in the install and one user could be using version Y while one user could be using version X. Is there a use-case where an individual user would need multiple versions of a bundle concurrently? Is this an exercise or do we really need to support multiple versions per user? To put it another way, if the bundles.txt belongs to the user and is not shared (and we don't expect to have to support multiple versions for a user) then a significant portion of Pascal's questions go away.

>>In the system: Let's say that I have junit 3.8.1 and junit 4.1 installed (boths are singleton) I am assuming you mean "P2 installed". I would not agree with this condition. How can you have both installed if they are singletons? For p2, installed means resolved, right? Also at a higher level we need to cover singletons if it isn't covered here. An example of that might be a native service packaged as bundle. In the process of installing it might change system behavior and no longer be multiple version compatible.

>>The problem we have now is that we lose information between the Director/Engine and the simple configurator.
Once we are at the engine level and below, we should just install and uninstall the exact versions specified. The decisions about which one to choose has been made. Did I miss something?

I am passing on the rest until I get clarification on the above.

Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>

Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>

Sent by: equinox-dev-bounces@xxxxxxxxxxx

12/10/2007 03:26 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] [prov] install / uninstall / update (was Configuration Admin bug)

It may be interesting to consider that during the provisioning operation, we do (may) know enough context to describe updates vs. uninstall/install. The problem we have now is that we lose information between the Director/Engine and the simple configurator. Not sure exactly how to retain the required information but seems like we should be able to.

The other thought that popped into my head relates to how the location of a bundle is defined. Right now we use some munged version of the bundle's physical location or some such. As has been pointed out, the actual value in the string is not important to the system. Perhaps we ought to abstract the location value such that, for example, all singleton bundles have a location that is just the bundle symbolic name. Then, as the bundle is *updated* the location still "makes sense". Well, it not clear how much sense this thought makes but it may be interesting.

Jeff

Pascal Rapicault/Ottawa/IBM@IBMCA
Sent by: equinox-dev-bounces@xxxxxxxxxxx

12/07/2007 01:18 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	[equinox-dev] [prov] install / uninstall / update (was Configuration Admin bug)

The bundle.getLocation() does not matter, but since so many systems are used around that it is also problematic to not having meaningful. For clarification to the casual reader, simple configurator does not explicitly have two lists. The lists of things to install and to uninstall are actually derived by analysing what is in the system and what the system should look like. Now for the corner cases (in each case the bundles.txt described lists all the bundles): Example 1: In the system: Let's say that I have junit 3.8.1 and junit 4.1 installed (boths are singleton) case 1) In the bundles.txt: I have junit 5.0 - Do I update the two bundles ? Do I update the highest one or the lowest one, why? case 2) In the bundles.txt I have junit 3.8.2 - Is it an update or a donwgrade? case 3) In the bundles.txt I have junit 3.8.4 and junit 4.0 - Which one is really an update? Example 2: In the system: Let's say that I have foo 1.0.0 (it is singleton) case 1) In the bundles.txt I have foo 1.1 and foo 1.2 (these are no longer singleton) - Which bundle do I pick to be an update of the one present? Example 3: In the system: Let's say that I have bar 1.0.0 and bar 2.0.0 (both are non singleton) case 1) In the bundles.txt I have bar 1.5 (singleton). - Which one do you update? Why? The other problem with updates, is that given two systems starting from the same initial state, if they are submitted to different bundles.txt over time to finally get to the same one. Even though the resulting systems look the same it is not clear that they will actually behave the same depending on what the data file may contain. Another one in that space is, someone starting fresh and someone applying a bundles.txt over a system may not end up with the same runtime behavior (of course bundles should all be written properly, etc.... but you know the truth :-)) PaScaL From: Thomas Watson <tjwatson@xxxxxxxxxx> To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx> Date: 12/07/2007 12:15 PM Subject: Re: [equinox-dev] Configuration Admin bug I'm not sure I understand this ... Simple configurator has two lists 1) a list of bundles it thinks need to be uninstalled 2) a list of bundles it thinks it need to be installed. Right now the configurator uninstalls all the bundles in uninstallList and then installs all the bundles in installList, but couldn't something like the following be used instead. for (each bundle in uninstallList) { if (another version of bundle exists in installList) { update(bundle with installList bundle content) remove installList bundle from installList } else uninstall(bundle) } for (each bundle in installList) { install(bundle) } Where this breaks down is if you want to have "meaningful" bundle locations (returned by Bundle.getLocation()) that somehow point to the actual location on disk. When using Bundle.update() this location String remains constant, just like the Bundle ID. Tom (Embedded image moved to file: pic12713.gif)Inactive hide details for Pascal Rapicault ---12/07/2007 10:44:27 AM---In fact I don't know of any management agent capable of Pascal Rapicault ---12/07/2007 10:44:27 AM---In fact I don't know of any management agent capable of calling update in (Embedded image (Embedded image moved to file: pic32339.gif) moved to file: Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx> pic24183.gif) From: (Embedded image (Embedded image moved to file: pic24964.gif) moved to file: Equinox development mailing list pic01888.gif) <equinox-dev@xxxxxxxxxxx> To: (Embedded image (Embedded image moved to file: pic12876.gif) moved to file: 12/07/2007 10:44 AM pic16290.gif) Date: (Embedded image (Embedded image moved to file: pic10201.gif) moved to file: Re: [equinox-dev] Configuration Admin bug pic15037.gif) Subject: In fact I don't know of any management agent capable of calling update in the way a user could do on the command line since the definition of update support updating any bundle into any other... In p2 we have explored solutions to this problem and were able to come up with a solution for the trivial cases (singleton bundles) however as soon as more complex cases showed up it seemed like any guessing of what an update would be looked completely random. Therefore we have decided not to support that. From: Thomas Watson <tjwatson@xxxxxxxxxx> To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx> Date: 12/07/2007 11:15 AM Subject: Re: [equinox-dev] Configuration Admin bug Another issue here is how bundles are updated to new versions. The CM implementation uses the BundleContext.getDataFile method to obtain a location to persistently store its data. This data area is unique to the Bundle ID (long value). When a bundle is updated (using Bundle.update method) the updated content of the bundle uses the same ID and therefore can obtain the same data file location as the previous version of the bundle. Some management agents (*cough* old Eclipse Update and p2) update bundles by first uninstalling the old version and installing a new version. This means the new version of the bundle will have a different location and a different Bundle ID. This has two implications on CM. First of all, it will cause the all persistent data from the old version of CM to be lost for the new version of CM. Second, since bundle locations change (locations are used to bind CM configurations) the existing bindings will be reset for bundles that are updated to new versions. Tom (Embedded image moved to file: pic23727.gif)Inactive hide details for Simon Kaegi ---12/07/2007 09:51:37 AM---Glad it's working now...Simon Kaegi ---12 /07/2007 09:51:37 AM---Glad it's working now... (Embedded image (Embedded image moved to file: pic06426.gif) moved to file: Simon Kaegi <Simon_Kaegi@xxxxxxxxxx> pic02520.gif) From: (Embedded image (Embedded image moved to file: pic26419.gif) moved to file: Equinox development mailing list pic31119.gif) <equinox-dev@xxxxxxxxxxx> To: (Embedded image (Embedded image moved to file: pic09978.gif) moved to file: 12/07/2007 09:51 AM pic11633.gif) Date: (Embedded image (Embedded image moved to file: pic08718.gif) moved to file: Re: [equinox-dev] Configuration Admin bug pic25032.gif) Subject: Glad it's working now... You're point about compatability of the store data is really interesting (I think so at least). In terms of technical details as part of the graduation work we switched from using regular files to the frameworks ReliableFile infrastructure. This does change the layout on disk and so is not backwards compatible with the original File approach. As you mention this change will not work when "updating" your bundle from the earlier approach. Once the component graduates I would expect this storage format to be relatively stable. In terms of a real long term solution I thinks it's inevitable that we're going to run into "incompatible" bundle data in the CM bundle and others and in these cases we perhaps should look at using provisioning infrastructure. Deployment Admin had the notion of "Customizers" to handle these sorts of changes and this sort of thing is definitely in scope for p2. -Simon equinox-dev-bounces@xxxxxxxxxxx wrote on 12/06/2007 04:27:40 PM: > > Oops, I made a mistake in the last run. I did not notice that there were two > cm bundles loaded and I was continuing to bind to the other one. > > The new cm bundle provided by Thomas does not have the problem. > > But I did notice one thing. When I changes the bundle for cm to the new > bundle, the old configurations that were stored were no longer visible. Is > that the behaviour you would expect? If so, that is a bad thing. At least it > is bad for us. We would need to ensure the configs get preserved across > updates to cm. If cm is completely replaced by a different implementation, > then of course you cannot expect the configs to be preserved. > > Thanks! > -Don > > On 12/6/07 2:28 PM, "Simon Kaegi" <Simon_Kaegi@xxxxxxxxxx> wrote: > > > Don, > > > > Could you provide a more detailed test case. > > The code specifically checks for a null BundleLocation so I suspect you're > > getting an NPE for another reason. > > > > The code has been significantly refactored so that the relevant check I > > think you're referring to is now in > > org.eclipse.equinox.internl.cm.ConfigAdminImpl line 48. > > > > if (config.getBundleLocation() != null && > > !config.getBundleLocation().equals(bundle.getLocation())) > > > > Could you verify that this is still the NPE cause and if not it would be > > great to know where it's coming from. > > > > Thanks. > > -Simon > > > > equinox-dev-bounces@xxxxxxxxxxx wrote on 12/06/2007 02:08:52 PM: > > > >> > >> Yes, the problem still seems to be there in that version. > >> > >> -Don > >> > >> > >> On 12/6/07 1:05 PM, "Thomas Watson" <tjwatson@xxxxxxxxxx> wrote: > > > >> This has already been fixed in the latest version of CM. Can you > >> try the latest build at > >> > >>http://download.eclipse. > >> org/eclipse/equinox/drops/I20071204-1547/download.php?dropFile=org. > >> eclipse.equinox.cm_1.0.0.v20071203.jar > >> > >> Tom > >> > >> > >> > >> [image removed] "Laidlaw, Don" ---12/06/2007 11:32:36 AM---In org. > >> eclipse.equinox.cm.internal.ConfigurationAdminFactory at line 812. > >> > >> [image removed] > >> From:[image removed] > >> "Laidlaw, Don" <don.laidlaw@xxxxxxxxx> > >> [image removed] > >> To:[image removed] > >> Equinox development mailing list <equinox-dev@xxxxxxxxxxx> > >> [image removed] > >> Date:[image removed] > >> 12/06/2007 11:32 AM > >> [image removed] > >> Subject:[image removed] > >> [equinox-dev] Configuration Admin bug > >> > >> > >> > >> > >> In org.eclipse.equinox.cm.internal.ConfigurationAdminFactory at line 812. > >> > >> The line: > >> if (!config.getBundleLocation().equals(bundle.getLocation())) > >> > >> The config.getBundleLocation() can sometimes return null. This is > >> especially true in a new factory configuration created by an admin > >> bundle with a null location. So in this case it will throw NPE. > >> > >> The workaround is to always provide a location, but this is not > >> required by the spec, and in fact you may want to create the > >> configuration before the bundle is installed. > >> > >> Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | > >> mobile: 416-543-1085 | don.laidlaw@xxxxxxxxx > >> _______________________________________________ > >> equinox-dev mailing list > >> equinox-dev@xxxxxxxxxxx > >>https://dev.eclipse.org/mailman/listinfo/equinox-dev> >> > >> > >> _______________________________________________ > >> equinox-dev mailing list > >> equinox-dev@xxxxxxxxxxx > >>https://dev.eclipse.org/mailman/listinfo/equinox-dev> >> > >> > >> Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | > >> mobile: 416-543-1085 | don.laidlaw@xxxxxxxxx > >> _______________________________________________ > >> equinox-dev mailing list > >> equinox-dev@xxxxxxxxxxx > >>https://dev.eclipse.org/mailman/listinfo/equinox-dev> > > > _______________________________________________ > > equinox-dev mailing list > > equinox-dev@xxxxxxxxxxx > >https://dev.eclipse.org/mailman/listinfo/equinox-dev> > Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | mobile: > 416-543-1085 | don.laidlaw@xxxxxxxxx > > > _______________________________________________ > equinox-dev mailing list > equinox-dev@xxxxxxxxxxx >https://dev.eclipse.org/mailman/listinfo/equinox-dev_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/equinox-dev_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/equinox-dev(See attached file: pic23727.gif)(See attached file: pic02520.gif)(See attached file: pic06426.gif)(See attached file: pic31119.gif)(See attached file: pic26419.gif)(See attached file: pic11633.gif)(See attached file: pic09978.gif)(See attached file: pic25032.gif)(See attached file: pic08718.gif)_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/equinox-dev(See attached file: pic23727.gif)(See attached file: pic02520.gif)(See attached file: pic06426.gif)(See attached file: pic31119.gif)(See attached file: pic26419.gif)(See attached file: pic11633.gif)(See attached file: pic09978.gif)(See attached file: pic25032.gif)(See attached file: pic08718.gif)_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/equinox-dev_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/equinox-dev
(See attached file: pic12713.gif)(See attached file: pic24183.gif)(See attached file: pic32339.gif)(See attached file: pic01888.gif)(See attached file: pic24964.gif)(See attached file: pic16290.gif)(See attached file: pic12876.gif)(See attached file: pic15037.gif)(See attached file: pic10201.gif)(See attached file: pic23727.gif)(See attached file: pic02520.gif)(See attached file: pic06426.gif)(See attached file: pic31119.gif)(See attached file: pic26419.gif)(See attached file: pic11633.gif)(See attached file: pic09978.gif)(See attached file: pic25032.gif)(See attached file: pic08718.gif)_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/equinox-dev