Bug 340010

Comment 1 Stephan Eberle 2011-03-17 11:13:00 EDT

(In reply to comment #0)
> The EditingDomainFactoryListenerRegistry creates all listener classes that are
> contributed via the org.eclipse.sphinx.emf.editingDomainFactoryListeners
> extension point from the constructor. This trigger of course the initialization
> of all plugins that contribute to the above mentioned extension and all other
> plugins that they might depend on. The creation of the
> EditingDomainFactoryListenerRegistry  happen quite early in an application life
> time; depending on the workspace status even during startup.

I agree that this may lead to critical situations and should be avoided.

> The listeners shall be created to the last possible moment, eg: right before
> notification for a particular model need to be broadcast to the listeners. 

I could imagine a similiar approach as in the EPackage.Registry for that purpose: by the time where we read the extension point contributions (called from the constructor of EditingDomainFactoryListenerRegistry) we do not create the extension (see #readContributedEditingDomainFactoryListeners(), line 91) but only retrieve its class (just as in org.eclipse.sphinx.emf.metamodel.MetaModelDescriptorRegistry#readContributedDescriptors(), line 175). We then store the listener class rather than the listener object, i.e., in very much the same way as the EPackageRegistry deals with EPackage descriptors instead of the real EPackages until the latter are really needed.

This way the creation of listener objects from the registered listener classes can be delayed until org.eclipse.sphinx.emf.domain.factory.EditingDomainFactoryListenerRegistry#getListeners(IMetaModelDescriptor) is called.

> And
> it shall create only the listeners that are bound to that particular
> IMetaModelDescriptor.

I don't think that this applies. Each listener is created only once and then bound to one or several IMetaModelDescriptors. I think that we can stay with that even when the creation takes place at a later time than now.

Comment 2 Robert Kiss 2011-03-23 03:55:33 EDT

Created attachment 191729 [details]
Patch

Patch attached for late initialization of listeners. However, the model plugins are still initialized because the internal maps uses the IMetaModelDescriptor as keys which are defined by the model plugins.

Comment 3 Robert Kiss 2011-03-23 04:57:38 EDT

It has been already mentioned by comment #2 that the model plugin initialization still happen because the map used to keep the listeners use as keys the IMetaModelDescriptor's. Of course this trigger the initialization of the plugins that holds that descriptors which usually are exactly the model plugins.

We could instead of using the IMetaModelDescriptor as keys to use only the model ID as keys. However there is one reason that prevent us to doing that, on the getListeners() method the following statement is present:

if((registeredMMDescriptor.getClass().isInstance(mmDescriptor))

Of course, if we switch to using IDs instead of descriptors we cannot have the same behavior.
Looking at the provided examples (Hummingbird) we can see that if someone request the listeners for "HummingbirdMMDescriptor" it will receive all listeners set for either "HummingbirdMMDescriptor" or any subclass of it. If we switch to strings it will return the listeners set only for that particular descriptor.

Changing the key from IMetaModelDescriptor to string will not solve the problem unfortunately because the IMetaModelDescriptors will still be initialized from other places, initialization that we cannot avoid. We can avoid however to initialize the models if the descriptors are initialized by moving the descriptors out of the model plugins.

Comment 4 Stephan Eberle 2011-03-30 17:18:16 EDT

Fixed by applying proposed patch. 

While doing so, I took the liberty to replace the
 
	void createAndAddListeners(Set<ITransactionalEditingDomainFactoryListener> result, Map<String, Object> listenersOrDescriptors)
	
method in the patch by a

	Set<ITransactionalEditingDomainFactoryListener> getListeners(Map<String, Object> listenersOrDescriptors)

method. Rationale: mostly cosmetic, but I prefer methods providing their result as return value than via one of their parameters.

Comment 5 Balazs Grill 2021-07-14 02:17:02 EDT

Mass-closing Resolved tickets