[jbosstools-issues] [JBoss JIRA] (JBIDE-22911) Exception below RenameMethodParticipant$RenameMethodSearcher.outOfSynch (thrown in Thread.getStackTrace)

Tue Aug 9 16:04:00 EDT 2016

    [ https://issues.jboss.org/browse/JBIDE-22911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277000#comment-13277000 ] 

Viacheslav Kabanovich commented on JBIDE-22911:
-----------------------------------------------

Ok, I see, the problem was stated in  https://community.jboss.org/message/800166#800166. But the main issue was not that a warning was annoying but that the rename operation was blocked (then 'fatal error' level was used instead of 'warning'). Yes, if user has 50 projects and it is a normal state of matters that something is always out of sync, then warning page may annoy, but in my opinion logged errors annoy more by causing worries that something is wrong with the tool. 

One thing user was complaining at was that the operation was blocked when out-of-sync resources were completely irrelevant. But actually, it seems that JBIDE-13695 did not fix the problem as the user stated it. Now, the operation is not blocked, an error is logged (or warning is shown), but the rename is aborted at the first out-of-sync resource, even irrelevant. The user's complain 'I'm ending up with permanently manually replacing method names' remained unfixed. 
To fix that it is not enough to change logging by warning, but do the best to collect all possible changes and just count out-of sync and read-only resources (for read-only we may guess if they are relevant by reading content from disk, if they are not relevant - just ignore them! ) then let user see as usual the proposed modifications for him to decide if he wants to proceed or not.

Comparing to Java rename participant, it does block renaming when a resource is out-of-sync but _only_ if it is relevant, that is if it had occurrences to change. We cannot provide 100% relevance and that is why log an error after aborting our participant (which I admit now is even correct because it every time cries of the bug in our tool). Still, I think we can improve it by not reporting/aborting on files that we _can_ prove as irrelevant.

> Exception below RenameMethodParticipant$RenameMethodSearcher.outOfSynch (thrown in Thread.getStackTrace)
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBIDE-22911
>                 URL: https://issues.jboss.org/browse/JBIDE-22911
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: jsf
>    Affects Versions: 4.3.1.Final
>            Reporter: Automated Error Reporting Bot
>            Assignee: Viacheslav Kabanovich
>             Fix For: 4.4.x
>
>
> The following problem was reported via the automated error reporting:
> Message: HIDDEN
> {noformat}
> java.lang.Exception: HIDDEN
>     at java.lang.Thread.getStackTrace(null:-1)
>     at org.jboss.tools.jsf.ui.el.refactoring.RenameMethodParticipant$RenameMethodSearcher.outOfSynch(RenameMethodParticipant.java:145)
>     at org.jboss.tools.jst.web.kb.refactoring.RefactorSearcher.scanProject(RefactorSearcher.java:148)
>     at org.jboss.tools.jst.web.kb.refactoring.RefactorSearcher.scanProject(RefactorSearcher.java:108)
>     at org.jboss.tools.jst.web.kb.refactoring.RefactorSearcher.findELReferences(RefactorSearcher.java:166)
>     at org.jboss.tools.jsf.ui.el.refactoring.RenameMethodParticipant.checkConditions(RenameMethodParticipant.java:58)
>     at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:257)
>     at org.eclipse.ltk.core.refactoring.Refactoring.checkAllConditions(Refactoring.java:162)
>     at org.eclipse.jdt.internal.ui.refactoring.RefactoringExecutionHelper$Operation.run(RefactoringExecutionHelper.java:80)
>     at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39)
>     at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:729)
>     at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2241)
>     at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:5409)
>     at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:106)
>     at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)
> {noformat}
> Bundles:
> | org.eclipse.core.resources | 3.10.1.v20150725-1910 | 3.11.0.v20160503-1608 |
> | org.eclipse.jdt.core | 3.11.0.xx-201604081629-e45 | 3.12.0.v20160516-2131 |
> | org.eclipse.jdt.ui | 3.11.2.v20151123-1510 | 3.12.0.v20160525-1829 |
> | org.eclipse.jface | 3.11.1.v20160128-1644 | 3.12.0.v20160518-1929 |
> | org.eclipse.ltk.core.refactoring | 3.6.201.v20150819-1034 | 3.7.0.v20160419-0705 |
> | org.eclipse.ltk.ui.refactoring | 3.7.200.v20140625-1835 | 3.7.200.v20140625-1835 |
> | org.jboss.tools.jsf.ui | 3.7.1.Final-v20160330-2256-B84 | 3.8.0.Final-v20160610-0126-B1 |
> | org.jboss.tools.jst.web.kb | 3.7.1.Final-v20160331-0256-B96 | 3.8.0.Final-v20160609-2146-B2 |
> Operating Systems:
> | Linux | 3.19.0 | 4.2.0 |
> | MacOSX | 10.11.4 | 10.11.4 |
> | Windows | 6.1.0 | 10.0.0 |
> The above information is a snapshot of the collected data. Visit [this page|https://redhat.ctrlflow.com/reviewers/#!/problems/5730baa5e4b0ba8b6a15d8cc] for the latest data.
> Thank you for your assistance.
>  Your friendly error-reports-inbox.

--
This message was sent by Atlassian JIRA
(v6.4.11#64026)