[jbosstools-issues] [JBoss JIRA] (JBIDE-12070) CLONE - ArrayIndexOutOfBoundsException when opening a DSL Rule editor

[David Goldstein (JIRA)]

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

David Goldstein commented on JBIDE-12070:
-----------------------------------------

I think the bug was introduced in the move to Eclipse Indigo.  I took some code developed in 5.1 and 5.2 and brought it into Helios SR2 that was originally using 5.2.1 plugins for Eclipse after getting the bug seen in 5.4.  In Helios version opens the DSL Rule Editor for DSLR files.  However, trying to go to the "DRL Viewer" tab fails and removes the tab from the editing pane. I do not see a *.log file (other than install.log) under the Eclipse installation or in the workspace and no relevant log file seems to be in the DROOLS directory.


                
> CLONE - ArrayIndexOutOfBoundsException when opening a DSL Rule editor
> ---------------------------------------------------------------------
>
>                 Key: JBIDE-12070
>                 URL: https://issues.jboss.org/browse/JBIDE-12070
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: drools
>         Environment: - Windows XP
> - Eclipse Helios build 20100617-1415, SWT version 3.650
> - JBoss Drools Core build 5.1.0.v20100728-2128-H133-M2
>            Reporter: David Goldstein
>            Assignee: Kris Verlaenen
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
> Stack trace snippet: 
> java.lang.ArrayIndexOutOfBoundsException: 1
>      at org.eclipse.swt.custom.StyledTextRenderer.calculateClientArea(StyledTextRenderer.java:230)
>      at org.eclipse.swt.custom.StyledText.handleResize(StyledText.java:6165)
>      at org.eclipse.swt.custom.StyledText$7.handleEvent(StyledText.java:5658)
>      at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
>      at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
>      at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077)
>      at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1058)
>      at org.eclipse.swt.widgets.Control.WM_SIZE(Control.java:4813)
>      at org.eclipse.swt.widgets.Scrollable.WM_SIZE(Scrollable.java:291)
>      at org.eclipse.swt.widgets.Composite.WM_SIZE(Composite.java:1653)
>      at org.eclipse.swt.widgets.Canvas.WM_SIZE(Canvas.java:454)
>      at org.eclipse.swt.widgets.Control.windowProc(Control.java:4234)
>      at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341)
>      at org.eclipse.swt.widgets.Display.windowProc(Display.java:4873)
>      at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method)
>      at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2454)
>      at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80)
>      at org.eclipse.swt.widgets.Control.WM_WINDOWPOSCHANGED(Control.java:4970)
>      at org.eclipse.swt.widgets.Canvas.WM_WINDOWPOSCHANGED(Canvas.java:460)
>      at org.eclipse.swt.widgets.Control.windowProc(Control.java:4244)
>      at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341)
>      at org.eclipse.swt.widgets.Display.windowProc(Display.java:4873)
>      at org.eclipse.swt.internal.win32.OS.SetWindowPos(Native Method)
>      at org.eclipse.swt.widgets.Widget.SetWindowPos(Widget.java:1456)
>      at org.eclipse.swt.widgets.Control.forceResize(Control.java:1018)
>      at org.eclipse.swt.widgets.ScrollBar.getThumbTrackBounds(ScrollBar.java:464)
>      at org.eclipse.jface.text.source.SourceViewer$RulerLayout.computeScrollArrowHeights(SourceViewer.java:217)
>      at org.eclipse.jface.text.source.SourceViewer$RulerLayout.getVerticalScrollArrowHeights(SourceViewer.java:196)
>      at org.eclipse.jface.text.source.SourceViewer$RulerLayout.layout(SourceViewer.java:155)
>      at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1275)
>      at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1261)
>      at org.eclipse.swt.widgets.Composite.layout(Composite.java:664)
>      at org.eclipse.swt.widgets.Composite.layout(Composite.java:622)
>      at org.eclipse.jface.text.source.CompositeRuler.layoutTextViewer(CompositeRuler.java:611)
>      at org.eclipse.jface.text.source.CompositeRuler.addDecorator(CompositeRuler.java:565)
>      at org.eclipse.jface.text.source.projection.ProjectionViewer.addVerticalRulerColumn(ProjectionViewer.java:1289)
>      at org.eclipse.jface.text.source.projection.ProjectionSupport.doEnableProjection(ProjectionSupport.java:310)
>      at org.eclipse.jface.text.source.projection.ProjectionSupport$ProjectionListener.projectionEnabled(ProjectionSupport.java:143)
>      at org.eclipse.jface.text.source.projection.ProjectionViewer.fireProjectionEnabled(ProjectionViewer.java:489)
>      at org.eclipse.jface.text.source.projection.ProjectionViewer.enableProjection(ProjectionViewer.java:537)
>      at org.eclipse.jface.text.source.projection.ProjectionViewer.doOperation(ProjectionViewer.java:1441)
>      at org.drools.eclipse.editors.AbstractRuleEditor.createPartControl(Unknown Source)
>      at org.eclipse.ui.part.MultiPageEditorPart.addPage(MultiPageEditorPart.java:241)
>      at org.eclipse.ui.forms.editor.FormEditor.addPage(FormEditor.java:325)
>      at org.eclipse.ui.part.MultiPageEditorPart.addPage(MultiPageEditorPart.java:211)
>      at org.eclipse.ui.forms.editor.FormEditor.addPage(FormEditor.java:308)
>      at org.drools.eclipse.dsl.editor.DSLRuleEditor2.addPages(Unknown Source)
>      at org.eclipse.ui.forms.editor.FormEditor.createPages(FormEditor.java:138)
>      at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:348) 
> The issue seems to be platform-dependent, as I'm not getting any exceptions in a gtk.linux.x86 build. 
> Some debugging revealed that StyledTextRenderer's internal data structures assume a different number of lines present than what content.getLineCount() returns in calculateClientArea(); these two values are usually kept in sync with the use of TextChangeListeners. I think that because of TransformedDocument's lazy update mechanism, new state can be returned to the renderer without firing a corresponding text change event first.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira