Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 2.0.0
-
Fix Version/s: 2.1.2
-
Component/s: Engine - General
-
Labels:None
Description
The singleton-implementation-discovery-style methods used in the current workbench, for instance FileManager.getInstance() - uses an InstanceRegistry to discover the implementation FileManagerImpl. (Due to the lack of using Spring/platform in the workbench).
Now FileManager is an abstract class - and if you forget something on the classpath / plugin profile, calling the constructor new FileManagerImpl() might fail. If this happens, the InstanceRegistry tries to call the getInstance() method on FileManagerImpl instead. Although this method is static, it's of course still inherited from FileManager - which creates a new InstanceRegistry, which finds FileManagerImpl, attempts to call it's constructor, etc. etc. ad absurbum.
Now this is not really a bug in InstanceRegistry, but in how we have used it. When we move to using the platform we can't do these getInstance() hacks anymore, which should remove the problem. For now, this is something to be wary of, and hence put into Jira. 
Activity
- All
- Comments
- Work Log
- History
- Version Control
- Activity
Integrated in 
net.sf.taverna.t2.infrastructure #436
avoid SPI registry loop
net.sf.taverna.t2.infrastructure #436
avoid SPI registry loop
Fixed so it only calls getInstance() if constructor does not exist (which was not called before!) - and only if the getInstance() static method belongs in the same class (not a superclass)