[JBoss JIRA] (JBIDE-22911) Exception below RenameMethodParticipant$RenameMethodSearcher.outOfSynch (thrown in Thread.getStackTrace)
3:04 p.m.
[
https://issues.jboss.org/browse/JBIDE-22911?page=com.atlassian.jira.plugi...
]
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/5730baa5e4b0ba8b6a...] 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)
3530
days inactive
3530
days old
jbosstools-issues@lists.jboss.org
0 comments
1 participants
participants (1)
-
Viacheslav Kabanovich (JIRA)