Community
Participate
Working Groups
Found by using the new API Tooling on org.eclipse.rse.core: 1. SystemFilterSimple leaks "internal" SystemFilter via extends 2. RemoteServerLauncher leaks "internal" ServerLauncher via extends 3. SystemResourceManager leaks "internal" SystemResourceConstants via extends 4. SystemFilterReference leaks "internal" SystemReferencingObject via extends I think we should adress these for M6 if possible. I will take care of (3) since constant interfaces shouldn't ever be implemented anyways. Dave's can you please look at 1,2,4 and propose a fix - I'm not sure whether we should promote the "internal" classes to API or do something else e.g. an API Factory method like SystemFilterUtility.getSystemFilterSimple() rather than allowing the user to instantiate himself.
regarding 1. SystemFilterSimple should only implement ISystemFilter, but ISystemFilter is a subinterface of RSEModelObject. However, SystemFilterSimple is not persistable. In the long term ISystemFilter should not implement RSEModelObject, however to fix this leakage problem we can probably just move SystemFilterSimple out from underneath SystemFilter. However, I really like the alternative you suggest of using a factory method. This will allow us to bury SystemFilterSimple and redo the hiearchy later. There would need to be some tweaking done to ISystemFilter I think to make this happen. regarding 4. We can make SystemReferencingObject API.
factory method and making SystemReferencedObject API seem the right thing. DaveD can you do it? DaveM can you look at the #2 problem with RemoteServerLauncher?
I'll handle 1 and 4.
I'll handle 2.
To deal with 2, I've made ServerLauncher public, since it was intended to be extended by those wishing to provide their own server launchers. We don't have time right now, but in the future we may want to try to do away with these server launcher concepts (at lease in core) since I think they're only applicable to dstore.
To deal with 1 I've implemented SystemFilterUtil with a single method getSimpleFilter(String). This is now used wherever the constuctor was used. I've created a new type - ISystemModifiableContainer - that extends ISystemContainer and allows the contents of teh container to be explicitly set. SystemFilterSimple implements this. I've moved SystemFilterSimple to the internal plugin I've added setSubSystem and getSubSystem to the ISystemFilter. The contract details the implementations for transient and non-transient filters. To deal with 4 Moved SystemReferencingObject, SystemReferencedObject, SystemReferencingObjectHelper, and SystemReferencedObjectHelper from internal to external packages -- making them explicit API.
Committed.
