Community
Participate
Working Groups
When RSE starts up, a SystemProfileManager singleton is created (either by the RSEUIPlugin or, in case of headless, some Core classes). Creation of the Singleton leads to restoring profiles in SystemProfileManager.getSystemProfileManager(). Due to fixing bug 177155, this initialization can take some time and can be done deferred. Clients who want to do something automatically right after startup (for instance, automatically add some default nodes like the "Local" connection) need to wait until the profiles in the SystemProfileManger are fully restored. It is currently not clear when this "complete" flag can be set: is it right after the restore operation is complete, or is it only after the default "Local" system type has been added automatically? Can clients get the default "Local" connection lazily? Or is this just another connection which just happens to be created automatically at some time? We need API to - detect if SystemProfileManager is already initialized, - OR wait until it is fully initialized, - OR register for a callback to occur after it is initialized. Perhaps it would also make sense to define an Event that is fired when the Persistence Manager has finished restoring profiles into the SystemProfileManager. Please give ideas or comments.
API added to test if a particular persistence provider has completed loading profiles.
Perhaps I'm missing something, but I cannot see how a client can use this API. What the client needs to do, is wait on early startup of RSE until the persistence provider is fully initialized. Since any number of persistence providers can be registered, the client has no concept of what particular persistence provider it should wait for. The API you added might make sense for some client, but I think we need another method that can tell us whether ALL registered persistence providers are fully initialized (and thus the SystemProfileManager is ready to use).
Martin, perhaps I missed something, but isn't it what Dave had asked in the committer meeting? There can be only one active (default) persistence provider, correct? So we do know exactly which persistence provider would be used, don't we?
We can have multiple active persistence providers, but there are currently two restore methods. One restores all profiles, but at the cost of activating all the plugins associated with all providers. The other method restores those profiles assigned to a particular provider. If we restrict the API to just restoring all profiles, then we can have an API that determines if all profiles have been restored. How about if we remove the provider id argument and return a multistatus instead of a boolean? Each status would contain a provider id (its message) and whether or not it was complete, in progress, not started, or not requested (its code). The multistatus itself would be complete only if all were complete.
Hm, multistatus seems flexible but hard to handle for clients. My understanding was that when RSE starts up (some or all?) persistence providers start looking at the workspace or wherever they want to look for existing persisted profiles, and read them in. Not all persistence providers may be configured with an "autostart" property to do this, but some may. So, from a client's view, the RSE SystemView is fully populated if and only if all those persistence providers that are configured to "autostart" have done their job. Autostarting requires activating their plugins anyways. Clients would like to know when they can assume that the RSE Models are fully populated with the stuff that should have been read from disk (or elsewhere).
As it stands today, the startup sequence loads all profiles. Adding an "autostart" option to the providers is a great idea, but it currently does not exist. However, it should be very easy to add. Lets do this. 1) add an autostart=<boolean> attribute to the provider extension point, default is false. 2) the default provider is assumed to be autostart. 3) the startup sequence functions as it does now, but only loads and restores autostart providers 4) the query will return a boolean and take no argument. It will be false if any autostart provider is incomplete.
Sounds great for me.
Implemented as described above
(In reply to comment #6) So, when I understand (4) above right, the solution for clients is to do RSECorePlugin.getThePersistenceManager().isRestoreComplete()
[target cleanup] 2.0 M7 was the original target milestone for this bug
