Community
Participate
Working Groups
DStoreConnectorService.internalConnect() is pretty long and ugly to read. This ought to be cleaned up such that each server launch type (daemon, rexec, manual, etc.) has it's own overrideable method. Because these methods should be overrideable, this would introduce new protected methods - hence the API tag.
Created attachment 134105 [details] patch with splitting up of internalConnect() Martin, because of the new protected methods, this constitutes an API change. Is there any way, that we can get a change like this into 3.1 or will such changes have to wait?
Hm... I don't have much of a problem with adding API at this point as long as no API is broken. Unfortunately the patch is hard to read so I can't really see the changes. Is there any real business case behind making those new split up methods "protected"? Who would ever override dstoreConnectorService and override any of these methods? Could they also just be private? Usually, Eclipse Projects don't add API if there is no client for that API known.
(In reply to comment #2) > Hm... I don't have much of a problem with adding API at this point as long as > no API is broken. Unfortunately the patch is hard to read so I can't really see > the changes. > > Is there any real business case behind making those new split up methods > "protected"? Who would ever override dstoreConnectorService and override any of > these methods? Could they also just be private? > > Usually, Eclipse Projects don't add API if there is no client for that API > known. > There are a couple IBM products that extend DStoreConnectorService to provide certain customizations. By splitting this stuff up and making them protected, it's easier for these products to make their customizations.
ok, go for it
I've committed the change to cvs.
