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.
To reproduce create a new web project and replace the content of index.jsp with the following: <%@ include file="index.jsp" %> <% %> Do some editing and save the file. Build: NetBeans IDE 6.1 RC1 (Build 200804100130) VM: Java HotSpot(TM) Client VM, 1.6.0_02-b05, Java(TM) SE Runtime Environment, 1.6.0_02-b05 OS: Windows XP, 5.1, x86 User comments: opened JSP page STACKTRACE: (first 10 lines) java.lang.StackOverflowError at sun.nio.cs.UTF_8$Decoder.decodeArrayLoop(UTF_8.java:212) at sun.nio.cs.UTF_8$Decoder.decodeLoop(UTF_8.java:358) at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:544) at java.net.URI.decode(URI.java:2775) at java.net.URI.getPath(URI.java:1303) at java.io.File.<init>(File.java:373) at org.netbeans.modules.masterfs.filebasedfs.FileBasedURLMapper.getFileObjects(FileBasedURLMapper.java:117) at org.netbeans.modules.masterfs.MasterURLMapper.getFileObjects(MasterURLMapper.java:61) at org.openide.filesystems.URLMapper.findFileObject(URLMapper.java:213) at org.openide.filesystems.FileUtil.toFileObject(FileUtil.java:669)
The fix should be quite easy
I fixed the problem in SimplifiedJSPServlet in trunk (http://hg.netbeans.org/main/rev/f71fb4393d21), however StackOverflowError still happens in the JSP parser. According to ppisl this issue "has always been there and is non-fixable on our side". I suppose in this circumstances it should not block the 6.1 release and it can be considered a P2. Note that there is another problem: the IDE doesn't completely close after this occurs, the 'project close' hook is held on a lock.
Created attachment 60329 [details] IDE log + thread dump taken when the IDE was stuck on exit
Please tell me this isn't going to sneak past and make it into the FCS! If NB can't handle basic JSP parsing it will be the laughing stock of Java IDE's. Don't say "has always been there and is non-fixable on our side". If this is true, be VERY specific as to the problem, since this comes across like finger pointing (i.e. 'it's the JVM's fault' or 'it's the OS's fault'. I hit this issue with multiple Java web apps in NB6.1.RC. It occurs when including several other JSP files (not the recursivce example demonstrated at beginning of this thread). I have 15 or 20 JSP files that include 1 common file (nav_menu.jsp). The nav_menu.jsp is a mix of HTML, JSP blocks, embedded JSP inside HTML tags, and blocks of JavaScript. Overall it is pretty standard stuff.
It can only occur if there is a cycle (not necessarily as trivial as in the example) in the include relationship. We should signal a user error in such situation. I agree the current behavior is very bad, but I don't think it is bad enough to hold the release. The latter opinion is shared by other development and QE team members so yes, this issue is very likely to remain in 6.1.
Hi Adam, I thought you've always been a NetBeans proponent and you did a great job helping NetBeans win the hearts of developers, so it's surprising that you are now talking about NetBeans as the "laughing stock of Java IDE's". From what Tomasz is saying, this is only happening when you have a cycle - if not, then yes we have a real problem. Also, did this work in 6.0 for you? If it did, then we also have a real problem. Either way, we should consider this issue for a patch of NetBeans 6.1.
DOn't get me wrong, still a big NetBeans proponent, but i'm just very frustrated with this issue. I don't want to see something that affects core functionality (like JSP parsing) cause non-proponents to be able to have one more excuse to complain about NB. As I explained in my last post, I am indeed getting this exception : java.lang.StackOverflowError at sun.nio.cs.UTF_8$Decoder.decodeArrayLoop(UTF_8.java:212) at sun.nio.cs.UTF_8$Decoder.decodeLoop(UTF_8.java:358) in NB6.1RC using JSP's and include's but with NO cyclic includes. I have a few dozen JSP files that each use contain the line : <%@ include file="nav_menu.jsp" %>. The nav_menu.jsp does not contain any includes. I've inspected each JSP file and can find no evidence on any kind of cyclic referneces using includes or any other mechanism. Opening the same project in NB 6.0.1 FCS and the errors do not occur.
Upon further investigation, I have found an interesting new wrinkle to this problem. I examined my project files one by one and validated that there was absolutely no cyclic references using includes. However, I failed to check my WEB.XML file. In the web.xml file we had included this snippet : <jsp-config> <jsp-property-group> <url-pattern>*.jsp</url-pattern> <include-prelude>/login_check.jsp</include-prelude> </jsp-property-group> </jsp-config> Thus, when the application ran, any calls to any JSP page would automatically include the login_check.jsp page which did basic session checking for login purposes. Though this page itself does not contain any forwards or includes, I think the mere definition in the WEB.XML causes the issue. Since the INCLUDE-PRELUDE file itself is a JSP and the URL pattern specifies JSP pages, this probably creates the circular reference itself. My question is this, does the IDE's JSP syntax/highlighting algorithms take into account this type of INCLUDE-PRELUDE in its functioing when parsing/highlighting JSP page when they are opened in the Source Editor. With the XML snippet included in the web.xml file I would open a JSP page and the StackOverflow would occur. If I remove the XML snippet above, the error does not occur, so it would seem the INCLUDE-PRELUDE definitions in WEB.XML ARE IN FACT somehow taken into account by the parsing/highlighting algorithm. If the code could be modified to handle this cyclic possibility this issue could hopefully go away quickly in time for NB 6.1 FCS???
I am sorry I still cannot reproduce it can you please attach (or send directly to me) a sample project with steps to reproduce? Can you reproduce it with the latest FCS build?
Now can reproduce it with build #200806030004. But when I deploy such page on Tomcat 6.0.x, it fails the same way. So it is Tomcat bug and must be fixed on Tomcat side. Please file appropriate issue at http://issues.apache.org/bugzilla/index.cgi Closing as WONTFIX. To avoid the cyclic includes please use the .jspf ext for included JSPs. It should solve your problem.
*** Issue 147389 has been marked as a duplicate of this issue. ***
Created attachment 86489 [details] WebApplication65.tar.gz
Check attached sample app. It contains two jspf files which are located in WEB-INF/jsp/ folder and I always get StackOverflow exception. Moving fragment files to WEB-INF/jspf/ prevents the issue. Why should NB die just because I used preclude in web.xml? Deploying such an app to GF runs fine. Considering this exception report has 82 duplicates this is something worth to fix.
Created attachment 86499 [details] Part of the stack trace
Thanks David, it's great to have a reproducible case. Tomasz, can you please investigate? Thanks.
reproducible, it looks like the mechanism preventing infinite recursion was broken during migration to CSL
fixed http://hg.netbeans.org/web-main/rev/be0a7ca5947f
Integrated into 'main-golden', will be available in build *200908242212* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/be0a7ca5947f User: Tomasz Slota <tslota@netbeans.org> Log: #133078: StackOverflowError when editing JSP with circular reference in the include directive