Menu
▾
▴
#879 IntellijSarosLifecycle not Singleton
Currently, the IntellijSarosLifecycle is not a singleton thus it's possible to instantiate it multiple times. This can be reproduced for example by closing and reopening a project in IntelliJ and lead to faulty behaviour. A consequence for instance can be that the existence of multiple XMPPConnectionServices with some parts of Saros/I using one and other parts the other instance(s).
IntellijSarosLifecycle holds a reference to a project as a member, so considerations how to deal with reopening another project have to be made. For a first conversation about this, see this patch
The title of this bug entry is misleading as it already assumes what the problem is and how it can be fixed. In fact the solution "a singleton" approach does not reflect the problem very well.
The real problem is the opportunity to switch IntelliJ projects on the fly. The IntelliJ plugin is currently operating on project scope (was changed from application scope). Unfortunately it does not work well concerning the FileSystem implementation along with how IntelliJ performs Java class loading.
To my experience there is only one class loader that loads the plugin regardless of the project. As we have many different components that operates on application scope (whole network layer) and also have to some extend static variables, this would lead to shared states inside the application between different IntelliJ projects.
The easiest workaround in my opinion would be to only allow one project to be shared, i.e switching to another project is either not possible or will result in a session abort.