On Mar 5, 2010, at 2:30 AM, Karl Pauls wrote:
On Fri, Mar 5, 2010 at 10:53 AM, Guillaume Nodet <[email protected]>
wrote:
That reminds me of a problem I've hit recently, for which I'd be
interested to have more information on.
When you install a bundle, the information must be persisted by the
framework so that it will still be installed when you *restart* the
framework.
Now my question, is what means *restart* ?
If the framework is nicely shutdown (using systemBundle.stop() for
example), then restarted, I assume it must work.
Now, what if the process is abruptly killed or if
java.lang.Runtime.halt() is called after returning from the call ?
I've had the problem because equinox actually persists the system
changes asynchronously. Unfortunately if another bundle persists
some
information using
BundleContext#getDataFile()
things can become out of sync.
For example, consider the following bundle activator:
public void start(BundleContext context) throws Exception
{
String location = "http://host/bundle.jar";
File persist = bundleContext.getDataFile("installed");
if (!persist.exists()) {
bundleContext.installBundle(location);
OutputStream os = new FileOutputStream(persist);
os.write(location.getBytes());
os.close();
}
}
Consider that as a dummy initial provisioning system.
Now, your hope would be that if the installed file exists, the bundle
is installed, right ? Unfortunately, there's no guarantee around
that.
Actually, I think Felix guarantee that, but Equinox does not, and if
you kill the process right after the activator has been called, upon
restart, the bundle will not be installed anymore.
From my understanding of the spec this is not the expected behavior.
The bundle should have been in the cache directly after the
installBundle method returned.
In the cache is one thing. Persistently stored so that it remains
installed after a failure is another.
Guillaume, two things suddenly occur to me.
1) It seems to me that this asynchronous persistence behavior could be
an optional optimization that can be turned off. I say this because
it strikes me that that behavior does not adhere to the spec.
2) Why would you store the provisioning file in the "provisioner's"
private data space? Why not:
public void start(BundleContext context) throws Exception
{
String location = "http://host/bundle.jar";
if (!persist.exists()) {
Bundle bundle = bundleContext.installBundle(location);
File persist = bundlege.BundleContext( ).getDataFile("installed");
OutputStream os = new FileOutputStream(persist);
os.write(location.getBytes());
os.close();
}
}
That way if the container does "forget" about the bundle it will also
"forget" about the provision file in the "forgotten" bundle's data
space.
Regards,
Alan
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev