Community
Participate
Working Groups
Comments from Dani while reviewing bug 349105 The code could be improved for Juno: the life cycle of the MRU list is not well specified: it is created in the initializer which is not needed. I would either only create it in the getter or consider creating it in frameworkStart(). Maybe we could even remove the 'null' test in the getter and specify that 'null' will be returned if the bundle is not started. But I don't know the code well enough if it's safe to say that the getter must only be called on the started bundle.
(In reply to comment #0) > Comments from Dani while reviewing bug 349105 > > The code could be improved for Juno: the life cycle of the MRU list is not well > specified: it is created in the initializer which is not needed. I would either > only create it in the getter or consider creating it in frameworkStart(). Maybe > we could even remove the 'null' test in the getter and specify that 'null' will > be returned if the bundle is not started. But I don't know the code well enough > if it's safe to say that the getter must only be called on the started bundle. Unfortunately we cannot do this in frameworkStart() since createBundleFile() is called before this method when reifying the bundles from a cached installation. This happens long before activating the BundleContext for the framework. I think the best we can do for now is to use your first suggestion and stop creating the object in the initializer.
> Unfortunately we cannot do this in frameworkStart() since createBundleFile() is > called before this method when reifying the bundles from a cached installation. > This happens long before activating the BundleContext for the framework. And are we sure that it does not happen after the bundle got stopped? If not, clearing it on stop might be wrong too. Either a bundle should have no state, state while running or always - at least in an ideal world ;-).
Created attachment 198191 [details] patch and updated tests (In reply to comment #2) > And are we sure that it does not happen after the bundle got stopped? If not, > clearing it on stop might be wrong too. Either a bundle should have no state, > state while running or always - at least in an ideal world ;-). Unfortunately we are not dealing with a plain bundle here, instead it is the framework which still exists even after we have called out to the storage to shutdown. I have decided to fix MRUBundleFileList to be able to reuse the same instance in cases where the storage is reused when the framework is relaunched. This exposed some other issues with the storage manager that I have also fixed up to allow it to be reopened correctly.
One other comment on the tests. I put a test "testMRUBundleFileListExpectedToFail" in there that I expect should fail on the Linux machine. But this assumes the linux test machines have a ulimit that prevents 3000 files from being opened at the same time from a single process.
I released the patch but commented out the testMRUBundleFileListExpectedToFail method. I need to do some additional testing on Linux to make sure this test will fail and to improve the tests.
I opened bug349871 to continue improving the tests on Linux.
