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 [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> 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 > > > > [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > >> [image removed] > >> To:[image removed] > >> Equinox development mailing list <equinox-dev@eclipse.org> > >> [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 | [EMAIL PROTECTED] > >> _______________________________________________ > >> equinox-dev mailing list > >> equinox-dev@eclipse.org > >> https://dev.eclipse.org/mailman/listinfo/equinox-dev > >> > >> > >> _______________________________________________ > >> equinox-dev mailing list > >> equinox-dev@eclipse.org > >> https://dev.eclipse.org/mailman/listinfo/equinox-dev > >> > >> > >> Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | > >> mobile: 416-543-1085 | [EMAIL PROTECTED] > >> _______________________________________________ > >> equinox-dev mailing list > >> equinox-dev@eclipse.org > >> https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > _______________________________________________ > > equinox-dev mailing list > > equinox-dev@eclipse.org > > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | mobile: > 416-543-1085 | [EMAIL PROTECTED] > > > _______________________________________________ > equinox-dev mailing list > equinox-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev