This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | REGRESSION: IllegalStateException while trying to bind database table to table component in visual web | ||
---|---|---|---|
Product: | editor | Reporter: | _ deva <deva> |
Component: | Lexer | Assignee: | issues@editor <issues> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | alexpetrov, blaha, issac23, jbaker, krystyna, mkhramov, mmirilovic, mschovanek, ovk, sandipchitale, toel, wjprakash |
Priority: | P2 | Keywords: | REGRESSION |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Exception stack trace
Detailed lexer log with the exception at the end exception occurs when refreshing the page messages.log build 1108 log stacktrace |
Description
_ deva
2007-10-12 01:49:14 UTC
Created attachment 50759 [details]
Exception stack trace
Aha!, that is why the added component tags are not showing up in the JSP. This is certainly P1 for visualweb and very critical for us to have quick fix. A real blocker. There is certainly an error since some token lists are tripled in the TokenListList. I'll try to reproduce and fix. Created attachment 50817 [details]
Detailed lexer log with the exception at the end
*** Issue 118756 has been marked as a duplicate of this issue. *** Data binding is broken in visual web It should be fixed. There was a problem of marking removed token lists in a TokenListList structure. During the search for the problem I have also improved consistency checking of the token hierarchy and its updating process. Checking in TokenHierarchyOperation.java; /cvs/lexer/src/org/netbeans/lib/lexer/TokenHierarchyOperation.java,v <-- TokenHierarchyOperation.java new revision: 1.26; previous revision: 1.25 done Checking in TokenHierarchyUpdate.java; /cvs/lexer/src/org/netbeans/lib/lexer/TokenHierarchyUpdate.java,v <-- TokenHierarchyUpdate.java new revision: 1.10; previous revision: 1.9 done Checking in TokenListList.java; /cvs/lexer/src/org/netbeans/lib/lexer/TokenListList.java,v <-- TokenListList.java new revision: 1.13; previous revision: 1.12 Alex, please verify this bug today in trunk. Thanks, Petr Visual diffs: http://www.netbeans.org/source/browse/lexer/src/org/netbeans/lib/lexer/TokenHierarchyOperation.java.diff?r1=1.25&r2=1.26 http://www.netbeans.org/source/browse/lexer/src/org/netbeans/lib/lexer/TokenHierarchyUpdate.java.diff?r1=1.9&r2=1.10 http://www.netbeans.org/source/browse/lexer/src/org/netbeans/lib/lexer/TokenListList.java.diff?r1=1.12&r2=1.13 Verified on the latest trunk build (http://deadlock.netbeans.org/hudson/job/trunk/3985/): Product Version: NetBeans IDE Dev (Build 071016) Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b02 System: Windows XP version 5.1 running on x86 Milo, please merge the fix in beta2 branch. Thanks, Petr This was a problem in beta2 branch also. Was it fixed there? *** Issue 117147 has been marked as a duplicate of this issue. *** visualweb Data binding needs to be tested. I'm still seeing lexer errors using the 0710160000 nightly build Here's a use case to test 1) Create new web application using the Visual Web JavaServer Faces framework 2) From the Palette, drag and drop a Table component 3) In the Services tab, connect to Travel, expand and drag and drop the TRIP table onto the Table component 4) Save-all then close the page or refresh the page using the refresh button near the top of the page Get lexer exceptions see attachment Created attachment 51086 [details]
exception occurs when refreshing the page
Created attachment 51087 [details]
messages.log
It seems that the build I was using, 0710160000 did not contain the fix for this issue. After updating the sources and building, binding is working fine, thanks *** Issue 117147 has been marked as a duplicate of this issue. *** Integrated in release60_beta2 branch. Checking in lexer/src/org/netbeans/lib/lexer/TokenHierarchyOperation.java; /cvs/lexer/src/org/netbeans/lib/lexer/TokenHierarchyOperation.java,v <-- TokenHierarchyOperation.java new revision: 1.25.2.1; previous revision: 1.25 done Checking in lexer/src/org/netbeans/lib/lexer/TokenHierarchyUpdate.java; /cvs/lexer/src/org/netbeans/lib/lexer/TokenHierarchyUpdate.java,v <-- TokenHierarchyUpdate.java new revision: 1.9.2.1; previous revision: 1.9 done Checking in lexer/src/org/netbeans/lib/lexer/TokenListList.java; /cvs/lexer/src/org/netbeans/lib/lexer/TokenListList.java,v <-- TokenListList.java new revision: 1.12.2.1; previous revision: 1.12 Alex, can you please verify this bug today in beta2 build? Verified on Product Version: NetBeans IDE 6.0 Beta 2 (Build 200710172300) Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b02 System: Windows XP version 5.1 running on x86 *** Issue 119067 has been marked as a duplicate of this issue. *** *** Issue 118163 has been marked as a duplicate of this issue. *** Using build 200710291200 I got this exception Which exception? Please attach the exception. Are you seeing the same issue as: http://www.netbeans.org/issues/show_bug.cgi?id=120458 ? I can't reproduced on (Derby, Glassfish V2, JavaEE 5/J2EE 1.4): Product Version: NetBeans IDE Dev (Build 200710291200) Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b02 System: Windows XP version 5.1 running on x86 JSF component Table was bound to DB table properly. I'm reopening this bug. This has happened several times to me while I was editing JSP in the Visual Web. Once happened, then anything I edit on the JSP, this exception dialog was poping up and the page gets screwed up. I'm using Hudson Build 4314. The problem is once this occurs, Visual Web modeling system throws "Illegal modification while Source dirty" exception and whole page gets screwed up. This leads to data loss. Look at the latest Exception I added for details. http://statistics.netbeans.org/exceptions/detail.do?id=4496 Sorry, but the particular build does not seem to contain the changes I have done in issue 120906 for some reason. If I now simulate the exception it looks like this (note "ETL: <0,3>" instead of "range[...]" etc.): Wishing to remove tokenList ETL: <0,3> IHC=1977511 T[0]: <null-text> <0,1> TEXT[0] DefT, la=1, st=0, IHC=30533424 T[1]: <null-text> <1,3> BRACES[1] ProT, la=1, st=1, IHC=27334345 but marked-for-remove tokenList is ETL: <0,3> IHC=1977511 T[0]: <null-text> <0,1> TEXT[0] DefT, la=1, st=0, IHC=30533424 T[1]: <null-text> <1,3> BRACES[1] ProT, la=1, st=1, IHC=27334345 from tokenListList TokenListList for text/x-join-sections-top/text/x-join-sections-text, joinSections [0]: ETL: <0,3> IHC=1977511 , <--REMOVED--> T[0]: <null-text> <0,1> TEXT[0] DefT, la=1, st=0, IHC=30533424 T[1]: <null-text> <1,3> BRACES[1] ProT, la=1, st=1, IHC=27334345 [1]: ETL: <7,10> IHC=14620722 ... I'm confident that the #120906 should eliminate this problem so I'm re-marking as fixed. Does this fix need to be applied to the 6.0 branch also ? According to this info (branch build == build 200711060000): "Subject: Branching for release60 Date: Tue, 06 Nov 2007 18:14:59 +0100 From: Robert Novak <Robert.Novak@Sun.COM> To: nb-tech <nb-tech@Sun.COM> Branch is being created to timestamp 200711060000. Integrations done after 00:00 GMT 11/06/2007 are not propagated to the branch. The list of branched modules is attached." I've tested DB area on the build #200711060000 today and this bug is not reproduced (Derby, Oracle, MySQL, PostrgreSQL). Right, both the original fix of this issue and fix of issue 120906 were done before release60 branching. Reopening. I ran automated tests last night using NB 200711060000 & woodstock B15 RC4 and have 1 serious and unexplained error with the staticText component. http://bsqe-giant.sfbay.sun.com/net/bsqe- falcon/export/home3/falcon15/rave/automation/results/nb6/results.200711060000.EE5.B15_RC4/testrun_071106- 202058/testbag_6/htmlresults/suites/TEST- org.netbeans.modules.visualweb.test.components.output.statictext.AcceptanceTest.html The IDE log is here: http://bsqe-giant.sfbay.sun.com/net/bsqe- falcon/export/home3/falcon15/rave/automation/results/nb6/results.200711060000.EE5.B15_RC4/testrun_071106- 202058/testbag_6/sys/ide/messages.log So far I have not been able to reproduce it manually. Looks like this is still not fixed. I checked this bug yesterday on NB 200711060000 and I've tried to reproduce it just now with Static Text (automatically and manually). It's not reproduced for me. Which version of Woodstock components was included into yesterday's build 200711060000? Woodstock B15 RC4 or not? And in my opinion results of manual testing have higher priority than results of automatic testing because automated tests are not always stable. Looks like lexer errors in the log, not ISE. REeopen #120906 ? RC3 was included with build 200711060000 by default. It is true that I can not reproduce this manually, and certainly not on demand. I was asked to re-open this because other developers are seeing it also. Please provide steps to reproduce before reopening, thanks! Steps from automatin: 1. Start IDE (new userdir) 2. Create EE5 project 3. Drag/drop Basic > StaticText onto designer Receive error. I can not reproduce this. I am re-running automation with today's bits. I will mark this bug INCOMPLETE, and if I can not reproduce using automation. I will close this again. Closing. This was no longer reproducible in the run against 200711070000. I just hit this again with today's build (200711080000) - log attached. I can't reproduce it a second time. Its definitely related to first drop. I think its a race condition. I think the component was dropped before the ide was really ready to accept it. Created attachment 52762 [details]
build 1108 log
I agree that this is a race condition since unlike the original problem (when the token list being removed was physically located in the TokenListList but it could not be found by the binary search because the offsets were incorrect) this time the token list being removed cannot be found in the TokenListList because there is an identical token list created for the same bounds but it's a different instance (the identity-hash-code differs). Is there a chance to reproduce with a reasonable number of attempts? Thanks. Its very difficult to reproduce manually, but I did run into it twice when running automation against the EE4 backwards compatibility kit on yesterday's (2007111207) RC1. http://bsqe-giant.sfbay.sun.com/net/bsqe- falcon/export/home3/falcon15/rave/automation/results/nb6/results.200711120000.EE4/testrun_071112- 120605/testbag_7/htmlresults/testbag.html http://bsqe-giant.sfbay.sun.com/net/bsqe- falcon/export/home3/falcon15/rave/automation/results/nb6/results.200711120000.EE4/testrun_071112- 180611/testbag_1/htmlresults/testbag.html I didn't run into this error error at all with automation until 200711060000. So far, it seems random. It isn't completely resolved - it happend again while editing a Bubble component, even with the current Woodstock 4.1.1 Netbeans update. See my Exception report for 4416. Product Version: NetBeans IDE 6.0 (Build 200711261600) Java: 1.6.0_02; Java HotSpot(TM) Client VM 1.6.0_02-b06 System: Windows XP version 5.1 running on x86; Cp1252; de_DE (nb) Sorry, but this bug isn't fixed, see exception report 4416 Product Version: NetBeans IDE 6.0 (Build 200711261600) Java: 1.6.0_02; Java HotSpot(TM) Client VM 1.6.0_02-b06 System: Windows XP version 5.1 running on x86; Cp1252; de_DE (nb) Is it possible that this regression is reinduced by the recent JSF update and the woodstock 4.1.1 netbeans module? THIS ISSUE HAS ALREADY 50 DUPLICATES The message which mentions the 50 duplicates comes from issue #118163 which is closed as duplicate of this issue. But by the users comments it looks like more general problem that a issue at database table to table component binding. Can some one from development evaluate the users reports attached to the duplicates: ( Issue #118756 and Issue #118163 ) ? I cannot reproduce on Nb 6.1 #200802080008 with WS 4.2 Build2_RC1. Jiai, please can you please try to reproduce with WoodStock 4.2 Build2 netbeans module? It should be released soon. This issue is mixture of too many unstable states earlier. It is impossible to discern the exact bug happening now from the soup of information from issues #118163, #118756 and #118163. Instead of re-opening this issue it is better to file another issue with exact informations. I completely agree with wjprakash to file a new issue since there were several bugfixes and rewrites of certain classes since NB6.0 and I hope the issue is no longer relevant for NB6.1. So please test and possibly file against _NB6.1_ Thanks. [65cat] Using the most current build (0802), the automated issue log hyperlinks me to this issue, which is marked resolved. Is there any way to update the link to point to a more accurate, and open issue? Reopening - reproduced in NetBeans IDE 6.1 (Build 200805300101) http://statistics.netbeans.org/exceptions/detail.do?id=126289 This should already be fixed - it happens with older builds only (20080530 or builds from August) so exceptions_reporter should not reopen this automatically => marking as fixed. Reopening - reproduced in NetBeans IDE Dev (Build 200810230201) http://statistics.netbeans.org/exceptions/detail.do?id=133829 Build: NetBeans IDE Dev (Build 200809270201) VM: Java HotSpot(TM) Client VM, 1.5.0_15-b04, Java(TM) 2 Runtime Environment, Standard Edition, 1.5.0_15-b04 OS: Windows XP, 5.1, x86 User Comments: Stacktrace: java.lang.IllegalStateException: Illegal source modification with dirty model C:\Work Files\NetBeansProjects\WebApplication1\web\Page3.jsp at org.netbeans.modules.visualweb.insync.SourceUnit.setSourceDirty(SourceUnit.java:304) at org.netbeans.modules.visualweb.insync.SourceUnit.removeUpdate(SourceUnit.java:388) at org.netbeans.lib.editor.util.swing.PriorityDocumentListenerList.removeUpdate(PriorityDocumentListenerList.java:99) at javax.swing.text.AbstractDocument.fireRemoveUpdate(AbstractDocument.java:242) at org.netbeans.editor.BaseDocument.fireRemoveUpdate(BaseDocument.java:1617) at org.netbeans.editor.BaseDocumentEvent.undo(BaseDocumentEvent.java:310) Created attachment 73081 [details]
stacktrace
This should already be fixed - I've reopened one of duplicates of this issue so this issue will not be reopened by exception reported |