| [gef3d-dev] Currently, Draw3D cannot define extension points |
Hi all,in order to fix bug https://bugs.eclipse.org/bugs/show_bug.cgi? id=261001 , I've moved the o.e.draw3d.graphics3d package into a separate plugin. While this fixes the bug, the reason why it was necessary to create a separate plugin is interesting for other issues, too.
Explanation:Plug-Ins defining extension points must be declared as "singleton". I call this plugin-singleton. A plugin-singleton is shared between all plugin using this plugin. In Java-words: All Java-singletons (see GOF singleton pattern) declared in a plugin-singleton are shared between all plugin instances. If a plugin is _not_ defined as singleton, every plugin (for example editor) creates its own Java-singletons. In other words: the plugin architecture and its special classloader enables multiple (Java-) singleton instances.
Currently, Draw3D and GEF3D are designed as non-plugin-singletons. That is a lot of Java-singletons are defined, and currently no special precautions are taken with respect to plugin-singleton requirements. For example, the RenderContext is defined as a (thread-local) singleton (note that thread-local-singletons do not solve the problem of plugin- vs. java-singletons), and it seems almost impossible to change that. This has a severe consequence: Draw3D cannot define extension points! We have to keep this in mind for future design issues.
The graphics3d stuff defines an extension point, this was the reason why we declared Draw3D as a plugin-singleton. The bug mentioned above was related to the problem described here: The singletons defined in Draw3D became plugin-singletons, that is they were shared between multiple editor instances. This became a problem with the texture and font managers, since these managers must be diposed when an editor is closed. But---and this is important to notice here---this was only the tip of the iceberg. While the texture manager must be bound to a GLCanvas (and we have to implement this in future versions, I have created a new bug report related to that), which would solve the singleton-problem in this special case, we would still run into problems with other singletons, such as the RenderContext (the problem with the disposed managers only prevented new errors to occur later). This is why I extracted the graphics3D stuff into a separate plugin (which was fortunately possible, no dependency cycles occurred!).
Maybe we could redesign Draw3D in order to declare it as a plugin- singleton. But I'm not sure if this is easy. Before creating the separate plugin, I tried to define thread-local singletons in order to fix the bug, but this didn't work. I'm not sure about that, but I figure that multiple plugins are run by the same thread! That is, a thread-local-java-singleton may be shared between different plugins, leading to the problems mentioned above.
Maybe we also should aware of this problem and try to avoid singleton in future design decisions if possible. The singleton pattern is known to be a problematic one, but often it is also the most easy one to implement...
Cheers Jens