[JBoss JIRA] Created: (JBIDE-6744) ArrayIndexOutOfBoundsException when opening a DSL Rule editor
by András Péteri (JIRA)
ArrayIndexOutOfBoundsException when opening a DSL Rule editor
-------------------------------------------------------------
Key: JBIDE-6744
URL: https://jira.jboss.org/browse/JBIDE-6744
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: drools
Affects Versions: 3.2.0.M2
Environment: - Windows XP
- Eclipse Helios build 20100617-1415, SWT version 3.650
- JBoss Drools Core build 5.1.0.v20100728-2128-H133-M2
Reporter: András Péteri
Assignee: Kris Verlaenen
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 contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JBIDE-6178) releng update site, feature naming conventions
by Darryl Miles (JIRA)
releng update site, feature naming conventions
----------------------------------------------
Key: JBIDE-6178
URL: https://jira.jboss.org/jira/browse/JBIDE-6178
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: updatesite
Affects Versions: 3.1.0.GA
Reporter: Darryl Miles
Priority: Minor
Please consider the impact of users using the "All Update Site" view when installing JBoss plugins.
Some rules to consider:
1) If JBoss creates a new top-level group (which consists entirely of JBoss features) then that top-level name should begin with the word "JBoss".
2) If JBoss reuses a top-level group which belongs to another vendor (for which JBT is built on top of, for example BIRT/Maven/DTP) then you can reuse the top-level group name of the outside vendor, but ensure your features underneath are prefixed with the word "JBoss"."
In enclose a screen grab from 3.1.0.GA which indicates the discrepancy; BIRT is following the above rules, but "Maven Support" is not (and also "Data Services" top level group is not).
The "All in one JBoss" top-level group doesn't really need to follow this convention, since the top level group clearly indicates it is from JBoss and entirely contains JBoss features and those features are a duplicated entrypoint for installation (i.e. each feature also exist somewhere else in the "features to install" tree view). The ambigiouty is over such names as "Maven Support" and "Data Services" in the context of the "all update site view" from the drop-down filter at the top of the page.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JBDS-1577) using JBDS as updatesite on eclipse works, but causes outofmemory because of name change
by Max Rydahl Andersen (JIRA)
using JBDS as updatesite on eclipse works, but causes outofmemory because of name change
----------------------------------------------------------------------------------------
Key: JBDS-1577
URL: https://issues.jboss.org/browse/JBDS-1577
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Bug
Components: updatesite
Affects Versions: 4.0.0.GA
Reporter: Max Rydahl Andersen
Not sure if this qualifies as a bug or a feature request but
I noticed that if I use JBDS 4 updatesite against plain Eclipse things seem to work great
until you restart (possible on the second restart) since then it suddenly has zero
extra memory allocated.
It only started working properly when using the jbdevstudio.app; thus my assumption is that
eclipse.ini is ignored and jbdevstudio.ini is looked for instead but this file is nowhere
to be found (except inside jbdevstudio.app)
Would be good if we could handle this situation more gracefully since the shortcuts users
uses still points to eclipse thus they will see it as JBDS running out of memory since when launching
it says JBDS.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JBIDE-8534) BIRT viewer should respect the locale attribute in an xhtml embedded report
by Dimitris Keramidas (JIRA)
BIRT viewer should respect the locale attribute in an xhtml embedded report
---------------------------------------------------------------------------
Key: JBIDE-8534
URL: https://issues.jboss.org/browse/JBIDE-8534
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: birt, JBossAS, Seam
Affects Versions: 3.2.0.Final
Environment: Windows 7 64-bit (x86), Eclipse Helios, Oracle jvm 1.6.0 update 23/24 (32bit), JBossAS 5.1, Seam 2.2.0, JBoss Tools 3.2.0, Birt Reporting Runtime Component 2.6.2
Reporter: Dimitris Keramidas
Assignee: Snjezana Peco
I have a simple report, using *.properties files for localization. When using the <b:birt/> tag to integrate the report in a .xhtml file (designType="embed"), the locale attribute is ignored. The documentation states that when using the "embed" parameter, only the designName and masterpage attributes may be used. However, this way the report always defaults to the JVM locale, and there is no - apparent - way to change the locale to match the user's preference. This behaviour does not apply when designType is "run" or "frameset".
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Created: (JBIDE-7783) GWT throws exceptions during Java field rename
by Daniel Azarov (JIRA)
GWT throws exceptions during Java field rename
----------------------------------------------
Key: JBIDE-7783
URL: https://jira.jboss.org/browse/JBIDE-7783
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: GWT
Affects Versions: 3.2.0.Beta1
Environment: JBoss Tools + GWT plugins
Reporter: Daniel Azarov
Assignee: Max Andersen
Test case:
1. Start JBDS
2. Create 'test' Java project
3. Create 'test' Java package
4. Create 'Test' Java class in 'test' package
5. Create 'int user' field
6. Select field and right-click on it
7. Select menu Source->Generate Getters and Setters then press OK button
8. Select field and right-click on it
9. Select menu Refactor->Rename then type user2 and press Ctrl+Enter
10. See Error log
FAIL:
java.lang.ClassCastException: org.eclipse.jdt.internal.core.SourceField cannot be cast to org.eclipse.jdt.core.IMethod
at com.google.gwt.eclipse.core.refactoring.GWTRenameParticipant.initialize(GWTRenameParticipant.java:115)
at com.google.gwt.eclipse.core.refactoring.GWTRenameMemberParticipant.initialize(GWTRenameMemberParticipant.java:38)
at com.google.gwt.eclipse.core.refactoring.rpc.PairedMethodRenameParticipant.initialize(PairedMethodRenameParticipant.java:224)
at org.eclipse.ltk.core.refactoring.participants.RefactoringParticipant.initialize(RefactoringParticipant.java:105)
at org.eclipse.ltk.core.refactoring.participants.ParticipantExtensionPoint.getParticipants(ParticipantExtensionPoint.java:100)
at org.eclipse.ltk.core.refactoring.participants.ParticipantManager.loadRenameParticipants(ParticipantManager.java:74)
at org.eclipse.jdt.internal.corext.refactoring.rename.RenameModifications.loadParticipants(RenameModifications.java:190)
at org.eclipse.jdt.internal.corext.refactoring.rename.JavaRenameProcessor.loadParticipants(JavaRenameProcessor.java:40)
at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:233)
at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckConditionsOperation.java:85)
at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:121)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
java.lang.ClassCastException: org.eclipse.jdt.internal.core.SourceField cannot be cast to org.eclipse.jdt.core.IMethod
at com.google.gwt.eclipse.core.refactoring.GWTRenameParticipant.initialize(GWTRenameParticipant.java:115)
at com.google.gwt.eclipse.core.refactoring.GWTRenameMemberParticipant.initialize(GWTRenameMemberParticipant.java:38)
at org.eclipse.ltk.core.refactoring.participants.RefactoringParticipant.initialize(RefactoringParticipant.java:105)
at org.eclipse.ltk.core.refactoring.participants.ParticipantExtensionPoint.getParticipants(ParticipantExtensionPoint.java:100)
at org.eclipse.ltk.core.refactoring.participants.ParticipantManager.loadRenameParticipants(ParticipantManager.java:74)
at org.eclipse.jdt.internal.corext.refactoring.rename.RenameModifications.loadParticipants(RenameModifications.java:190)
at org.eclipse.jdt.internal.corext.refactoring.rename.JavaRenameProcessor.loadParticipants(JavaRenameProcessor.java:40)
at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:233)
at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckConditionsOperation.java:85)
at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:121)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months