[ https://issues.redhat.com/browse/WFLY-13871?page=com.atlassian.jira.plugi... ] Richard Achmatowicz edited comment on WFLY-13871 at 9/16/20 10:45 AM: ---------------------------------------------------------------------- The option described above says: introduce a new listener type for the association to register, SuspendResumeListener, which involves changing the Association interface, the AssociationImpl and then cause that new listener to be registered in the EJBRemoteService. However, there is a short cut here that could simplify things considerably. Because the SuspendResumeListener depends on being able to send module updates back to the client, it will depend on having access to a ModuleAvailabilityListener, which *could* be the same instance as passed to the method registerModuleAvailabilityListener. The short cut is to not add in a new listener type to the Association, but simply register the SuspendResumeListener in the registerModuleAvailabilityListener method of AssociationImpl, at the same time that we register the "middleman listener" that uses the ModuleAvailabilityListener parameter. It makes sense because module availability is determined now by two things: what is happening in the deployment repository, as well as whether or not the server is suspended. It avoids complicating the Association interface with an extra method as well as the RemoteEJBService with an extra registration. The only possible negative side effect is that it doesn't make explicit the fact that a suspend resume listener is being registered, at the Association interface level. was (Author: rachmato): The option described above says: introduce a new listener type for the association to register, SuspendResumeListener, which involves changing the Association interface, the AssociationImpl and then cause that new listener to be registered in the EJBRemoteService. However, there is a short cut here that could simplify things considerably. Because the SuspendResumeListener depends on being able to send module updates back to the client, it will depend on having access to a ModuleAvailabilityListener, which *could* be the same instance as passed to the method registerModuleAvailabilityListener. The short cut is to not add in a new listener type to the Association, but simply register the SuspendResumeListener in the registerModuleAvailabilityListener method of AssociationImpl, at the same time that we register the ModuleAvailabilityListener. It makes sense because module availability is determined now by two things: what is happening in the deployment repository, as well as whether or not the server is suspended. It avoids complicating the Association interface with an extra method as well as the RemoteEJBService with an extra registration. The only possible negative side effect is that it doesn't make explicit the fact that a suspend resume listener is being registered, at the Association interface level. -- This message was sent by Atlassian Jira (v7.13.8#713008)