Community
Participate
Working Groups
N20050608-0010 Found this in my log. This seems to be a normal network connection problem, not a bug in Eclipse. It should not be written to the log. Could not connect to :aoeuaoeu:saoeuu@aoeuaoeu:/home/aouaoeu: I/O exception occurred: Connection refused: /home/aouaoeu: no such repository java.io.IOException: Connection refused: /home/aouaoeu: no such repository at org.eclipse.team.internal.ccvs.core.connection.PServerConnection.authenticate(PServerConnection.java:196) at org.eclipse.team.internal.ccvs.core.connection.PServerConnection.open(PServerConnection.java:108) at org.eclipse.team.internal.ccvs.core.connection.Connection.open(Connection.java:128) at org.eclipse.team.internal.ccvs.core.connection.CVSRepositoryLocation.createConnection(CVSRepositoryLocation.java:494) at org.eclipse.team.internal.ccvs.core.connection.CVSRepositoryLocation.openConnection(CVSRepositoryLocation.java:735) at org.eclipse.team.internal.ccvs.core.client.Session.open(Session.java:149) at org.eclipse.team.internal.ccvs.core.resources.RemoteFolderMemberFetcher.performUpdate(RemoteFolderMemberFetcher.java:95) at org.eclipse.team.internal.ccvs.ui.operations.FetchMembersOperation$InternalRemoteFolderMemberFetcher.performUpdate(FetchMembersOperation.java:69) at org.eclipse.team.internal.ccvs.core.resources.RemoteFolderMemberFetcher.fetchMembers(RemoteFolderMemberFetcher.java:62) at org.eclipse.team.internal.ccvs.core.resources.RemoteFolderMemberFetcher.fetchMembers(RemoteFolderMemberFetcher.java:53) at org.eclipse.team.internal.ccvs.ui.operations.FetchMembersOperation.execute(FetchMembersOperation.java:107) at org.eclipse.team.internal.ccvs.ui.operations.CVSOperation.run(CVSOperation.java:79) at org.eclipse.team.internal.ccvs.ui.model.CVSTagElement.fetchDeferredChildren(CVSTagElement.java:134) at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:192) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76)
The error is logged by the Jobs framework. If you feel strongly about this, you can reopen it and assign it the Platform Runtime.
It appears that the exception is logged by CVSPlugin.openError. CVSModelElement passes all exceptions to this method, causing everything to be logged (bug or not). These appear to be CVS classes, not core classes... but cc'ing the talented Mr. Arthorne to confirm.
I'll take Stefan's word for it. Since it's a checked exception being logged, I don't think it could be the jobs framework logging it anyway.
Looks like the logic in the CVSUIPlugin#openError is wrong. The flag passed indicates that only non-team exceptions should be logged. However, the if checks for CoreExceptions first. Since a TeamException is a CoreException, it gets logged. Not high enough priority for 3.1 so assigning to 3.2.
We do not plan on addressing this issue in 3.3.
I think what we could do here is the check for TeamException _before_ checking for CoreException. Theoretically, if there were a check for a CVSException I would put it before all other checks as it's located lower in the classes hierarchy. This was my first thought, but I might be missing something. Maybe there is a reason why the checks are the other way round?
Created attachment 83860 [details] Patch Patch that puts check if an exception is a TeamException before checking for CoreException.
Szymon, could you take a look at the patch?
Created attachment 83982 [details] My proposal I would make a little change in the patch.
As the flags are exclusive, I think we don't have to (or even we shouldn't) check for LOG_CORE_EXCEPTIONS when an exception is of TeamException type. That's why I would stay with the first patch. Of course, we could comment those flags, to make sure they are properly used. BTW, applying your patch Simon, wouldn't fix the bug anyway.
Right, the names of the constants are confusing. Team Exceptions are Core Exceptions too. So either the code should be fixed or comments should be added. The appropriate comments are enough though.
On second thoughts, I think we should combine both patches (ie. add "|| (flags & PERFORM_SYNC_EXEC) > 0" to flag check for Team and Core Exceptions). I'm guessing here... Micheal, could you shed some light on how those flags are intended to be use? I've been tracking where and how they're set but I'd prefer not base only on my assumptions. I couldn't find any other clues.
I really don't recall what the semantics of the flags is supposed to be. I think it would make sense to separate the two flags. That is, the "log team" flag would log team exceptions and the "log core" would log core exceptions that are not team exceptions. Perhaps the name of the "log core" flag could be change to "log none team core" and you could create a combined flag called "log core" that conbined the two. This would make the semantics more explicit. As for the sync flag, you only need to set that if you are calling openError from a none UI thread. This flag was added before I knw the trick for determing if you ar ein the UI thread or not (i.e. Display.getCurrent() is null if you are not in the UI thread). It would be better to detect this in the opneError method and do the sync if required.
Created attachment 84311 [details] Patch #3
(In reply to comment #13) > I think it would make sense to separate the two flags. That is, the "log team" flag > would log team exceptions and the "log core" would log core exceptions that are > not team exceptions. Perhaps the name of the "log core" flag could be change to > "log none team core" and you could create a combined flag called "log core" that > conbined the two. This would make the semantics more explicit. Good idea. I've separated and described the flags. > It would be better to detect this [PERFORM_SYNC_EXEC flag] in the opneError method > and do the sync if required. It's done in openDialog method. Szymon, could you take a look at the latest patch? I hope this one will be more in your type :)
Released to HEAD.
Verified by code inspection.
