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.

Bug 123370 - JSP editor VERY slow.
Summary: JSP editor VERY slow.
Status: VERIFIED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: JSP Parser (show other bugs)
Version: 6.x
Hardware: PC Windows ME/2000
: P2 blocker with 2 votes (vote)
Assignee: Tomas Mysik
URL:
Keywords: PERFORMANCE
: 122973 123666 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-12-04 15:44 UTC by markjl9
Modified: 2008-03-20 18:48 UTC (History)
10 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Thread Dump 1 - Opening jsp (14.55 KB, text/plain)
2007-12-04 20:47 UTC, markjl9
Details
Thread Dump 4 - Closing a jsp (9.64 KB, text/plain)
2007-12-04 20:50 UTC, markjl9
Details
Thread Dump 2 - Saving jsp (14.65 KB, text/plain)
2007-12-04 20:50 UTC, markjl9
Details
Thread Dump 3 - Saving jsp (14.65 KB, text/plain)
2007-12-04 20:51 UTC, markjl9
Details
ThreadDump 5 - Added a couple of jar files to my classpath (15.03 KB, text/plain)
2007-12-04 21:04 UTC, markjl9
Details
Opening first JSP thread dump (30.74 KB, text/plain)
2007-12-11 14:04 UTC, markjl9
Details
3 thread dumps - few seconds after opening file, after few seconds and at the moment of finished CPU activity (46.55 KB, text/plain)
2007-12-11 18:40 UTC, Jindrich Sedek
Details
this stacktrace is catched during jsp file editation - cpu starts running for 100% for few seconds after cc invocation (21.45 KB, text/plain)
2008-01-04 10:18 UTC, Jindrich Sedek
Details
NetBeans Idle Thread Dump (8.97 KB, text/plain)
2008-01-23 15:41 UTC, fragou
Details
auto-completion in progress Thread Dump (15.90 KB, text/plain)
2008-01-23 15:42 UTC, fragou
Details
IDE Log File (42.41 KB, text/plain)
2008-01-23 15:42 UTC, fragou
Details
Profiler snapshot (open+paste+cc) (53.70 KB, application/octet-stream)
2008-01-28 13:48 UTC, Tomas Mysik
Details
Thread Dump During 2nd CC (18.44 KB, text/plain)
2008-01-30 12:54 UTC, fragou
Details
Test Project Tree (2.55 KB, text/plain)
2008-02-01 01:57 UTC, fragou
Details
Test Web Project (21.76 KB, text/plain)
2008-02-01 12:26 UTC, fragou
Details
module with improved logging (95.98 KB, application/octet-stream)
2008-02-07 10:43 UTC, Tomas Mysik
Details
Extended Log File (355.79 KB, text/plain)
2008-02-08 12:20 UTC, fragou
Details
new version of module (95.08 KB, application/octet-stream)
2008-02-12 13:00 UTC, Tomas Mysik
Details
Log File for Second Module (2.66 KB, text/plain)
2008-02-12 17:55 UTC, fragou
Details

Note You need to log in before you can comment on or make changes to this bug.
Description markjl9 2007-12-04 15:44:08 UTC
I'm not sure what has happened but the new 6.0 final version has the worst performance that I've used thus far and is
VERY frustrating to use(I have used both beta 6.0 versions and both 6.0 release candidates). Currently, if I am
switching between jsp pages (that I have opened in the editor) my machine basically becomes unusable (freezes) for
almost a minute...sometimes longer. Also, if I make a change and save it...my machine again becomes usable for another
minute or longer while I wait for NB to save it.
Comment 1 markjl9 2007-12-04 15:49:21 UTC
Also, it is very slow closing a jsp file. It is also slow switching from a java page to a jsp.
Comment 2 Marek Fukala 2007-12-04 15:58:12 UTC
Can you please attach a few threaddumps taken during the high CPU load?
Comment 3 markjl9 2007-12-04 20:47:19 UTC
Created attachment 53874 [details]
Thread Dump 1 - Opening jsp
Comment 4 markjl9 2007-12-04 20:50:27 UTC
Created attachment 53875 [details]
Thread Dump 4 - Closing a jsp
Comment 5 markjl9 2007-12-04 20:50:59 UTC
Created attachment 53876 [details]
Thread Dump 2 - Saving jsp
Comment 6 markjl9 2007-12-04 20:51:21 UTC
Created attachment 53877 [details]
Thread Dump 3 - Saving jsp
Comment 7 markjl9 2007-12-04 21:04:54 UTC
Created attachment 53879 [details]
ThreadDump 5 - Added a couple of jar files to my classpath
Comment 8 Marek Fukala 2007-12-05 15:18:35 UTC
Thanks for the threaddumps, but non of them is complete. Can you please remake them and attach the complete content? Is
it also possible to make them without the annoying line wraps? Thanks.

As for the particullar dumps:

#1 - opening JSP - in the visible part there doesn't seem to be anything special. Can you please confirm that the
opening time is slow for all JSP files. Or that project specific? Is there really a positiove difference in the opening
time between RCx and FCS? BTW Was the CPU loaded at all? Or just the UI was frozen? BTW, how long the opening take?

#2 - closing jsp - There is nothing going on in the "closing JSP" TD. Was the CPU loaded? How long the closing takes
until the file is closed?

#3 - saving jsp - there might be some parser problems, it is strange, I have never heard any complains about saving,
again the TD is not complete, please make it again.

Can you please specify your jdk, platform, CPU, memory etc? Also please provide some more precise description of what is
happening during the "slowenes" - whether CPU is loaded, or just UI frozen, how long the actions takes etc.

BTW, do you use local filesystem or remote one for your project? Can you reproduce after cleaning the userdir and
creating a new project?

Thanks for providing the data.

Comment 9 markjl9 2007-12-05 16:12:48 UTC
>
> BTW, do you use local filesystem or remote one for your project? Can you reproduce after cleaning the 
> userdir and creating a new project?
>
I would like to try this. How do I clean the 'userdir' for this project?
Comment 10 markjl9 2007-12-05 18:01:44 UTC
>
> Thanks for the threaddumps, but non of them is complete. Can you please remake them and attach the complete content? 
> Is it also possible to make them without the annoying line wraps? Thanks.
>
What is the recommended way of capturing these thread dumps?
Comment 11 Dan Kolar 2007-12-10 13:34:19 UTC
a)Your userdir is located in {your disk}:/Documents and Settings/{your username}/.netbeans/6.0
Deleting the whole folder (or /var folder in it, what keeps your configuration settings intact and has the same result)
you force NetBeans to recreate data cache and thus prevent problems with somehow corrupted cache (which is sometimes
also source of problem).

b)After pressing Ctrl-Break in command shell window, use Ctrl-A for "Select all" and paste to notepad to prevent insert
of unwanted chars (what could happen in Wordpad/MS Word and similar text editors). This shoulds retain original raw text
structure.
Comment 12 markjl9 2007-12-11 14:04:54 UTC
Created attachment 54146 [details]
Opening first JSP thread dump
Comment 13 markjl9 2007-12-11 14:16:32 UTC
Hi,

I just attached a new threaddump which was created while opening the first jsp page after the NB has just been started. 

By the way, I recreated my project and everything now seems to be working fine. However, I have noticed that the first
JSP page that I open after I have started NB (each day) nearly kills my machine for a minute or two. Once loaded,
everything is ok...at least for awhile. I also have noticed that if I'm not doing any jsp editing for awhile (maybe an
hour or so) and then I open a JSP the same thing happens to my machine (it becomes usable) and I have to wait a minute
or 2 before I can use it.
Comment 14 Marek Fukala 2007-12-11 14:55:05 UTC
It looks like the problem is jsp parser performance - how many libraries, jars, dependent projects and tlds do you have
in the project? 
Comment 15 Jindrich Sedek 2007-12-11 18:39:04 UTC
I can reproduce similar thread dump while opening logger/uihandlerserver module from NetBeans CVS and trying to open
uploaddone.jsp file. This scenario doesn't block IDE totaly, but it run CPU on 100% for few seconds.
Comment 16 Jindrich Sedek 2007-12-11 18:40:24 UTC
Created attachment 54158 [details]
3 thread dumps - few seconds after opening file, after few seconds and at the moment of finished CPU activity
Comment 17 markjl9 2007-12-12 13:59:22 UTC
>
> It looks like the problem is jsp parser performance - how many libraries, jars, dependent 
> projects and tlds do you have in the project? 
>
libraries - 1 (struts)
jars - 236
dependent projects - 0
tlds - 6
Comment 18 Marek Fukala 2007-12-12 14:11:46 UTC
Can I ask what are all these jars for? It looks like this is the reason - jsp parser parses all the jars on the
classpath so if you have so many of them it may take some time.
Comment 19 Jindrich Sedek 2008-01-04 10:18:46 UTC
Created attachment 54680 [details]
this stacktrace is catched during jsp file editation - cpu starts running for 100% for few seconds after cc invocation
Comment 20 jessholle 2008-01-04 13:51:15 UTC
We have lots of very large jars and a large loose codebase directory in our web classpaths -- and these are quite
necessary.  I'd expect the parsing results to be cached...

[Note I'm not in any way associated with the original reporter, but will be throwing in my vote for this issue.  Though
the NB 6 JSP editor is very nice overall, its performance is truly atrocious at the moment.]
Comment 21 Marek Fukala 2008-01-08 18:56:24 UTC
*** Issue 122973 has been marked as a duplicate of this issue. ***
Comment 22 Marek Fukala 2008-01-14 22:19:34 UTC
There are plenty of problems in this issue reported, the attached threaddumps shows different activities. This needs to
be investigated more thoroughly, not time for this now.
Comment 23 Marek Fukala 2008-01-14 22:33:28 UTC
*** Issue 123666 has been marked as a duplicate of this issue. ***
Comment 24 fragou 2008-01-23 15:39:23 UTC
I face similar issues when editing a .jsp file: 
If there is one or more taglib jsp directive in the page, and you open a tag by typing a '<' 
or press Ctrl-Space inside a non-jsp standard tag, the auto-completion box initiates('Please wait...' 
message is shown) and consumes a lot of CPU for a few seconds(10 to 30 as I noticed) until finaly
the pop-up menu become available. When I initiate auto-completion inside a standard jsp tag or if
there are no taglib directives, auto-completion responds immediately.

All of the above apply for my Windows XP box. I have NetBeans installed on a Linux laptop (Ubuntu 7.04)
with exactly the same configuration for NetBeans ,working with the same project through svn and there
no delays in auto-completion.

I will paste the contents of the test jsp file below(it's the auto-generated forwardToJSF.jsp, 
slightly modified):
-------------------------------------------------
<%@page pageEncoding="UTF-8"%>
<%@ taglib prefix="f" uri="http://java.sun.com/jsf/core" %>
<%@ taglib prefix="h" uri="http://java.sun.com/jsf/html" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%--
    This file forwards to the entry of JavaServer Faces application.
    See <welcome-file-list> in web.xml file.
--%>
<
<jsp:forward page="index.jsp"/>
--------------------------------------------------

I will attach the Thread Dumps I've taken, one with NetBeans idle, and one with auto-competion on 
the go. And just in case it's needed, I will also attach the NetBeans log.
Comment 25 fragou 2008-01-23 15:41:00 UTC
Created attachment 55441 [details]
NetBeans Idle Thread Dump
Comment 26 fragou 2008-01-23 15:42:07 UTC
Created attachment 55442 [details]
auto-completion in progress Thread Dump
Comment 27 fragou 2008-01-23 15:42:31 UTC
Created attachment 55443 [details]
IDE Log File
Comment 28 Marek Fukala 2008-01-24 20:51:48 UTC
Thanks for the detailed report.

From what you wrote, some other reports and the attached threaddump it looks like a problem with jsp parser, more
specifically with the TldLocationsCache. It looks like there is a lot of tld files to parse. 

"Init TldLocationCache" daemon prio=2 tid=0x2add2400 nid=0x770 runnable [0x2f6be000..0x2f6bfc94]
   java.lang.Thread.State: RUNNABLE
	at java.util.zip.ZipFile.open(Native Method)
	at java.util.zip.ZipFile.<init>(ZipFile.java:114)
	at java.util.jar.JarFile.<init>(JarFile.java:133)
 [snip]

btw, fragou, is the completion also that slow if you invoke it again, without modification of the document, and also if
you modify the document. To make it more clear:

1) open the jsp file
2) invoke the cc 
=> I guess now you wait for the 10-30 seconds.
3) close the cc (press ESC)
4) invoke again
=> is the time the same or is it faster?
5) close the cc again
6) modify the document 
7) invoke the cc again
=> what is the cc time now?

Thanks for clarifying also this.
Regards,
marek

Comment 29 Marek Fukala 2008-01-24 20:56:25 UTC
can someone from QE try to reproduce the problem on win XP? Please refer to markjl9's report for the approximate project
size. Thanks in advance.
Comment 30 fragou 2008-01-25 03:16:02 UTC
Ok, mfukala, following the steps you sugested here are the results:

First invocation of cc: ~10 secs.
Second invocation:	~10 secs again.
Invocation after editing: same results..

I performed a few more tests:

1) Removed the JSF taglib directives, leaving only the JSTL taglib. The file I'm editing is the one I included in my
first message -'forwardToJSF.jsp'. This time cc is faster, 4 seconds.

2) I'm using a lot of jar files in the web project, and as you said 'there are a lot of tld files to parse'. So I 
removed everything exept the JSTL library. CC performance is dramaticaly improved - it takes hardly 2 seconds to popup.

3) After that, I added again the largest library I'm using, witch is Hibrenate. It contains all the jars from 
Hibernate Core 3.2 and Hibernate Entity Manager 3.3.1GA. This time code completion takes around 7 seconds to popup.

Also I have to retract the statement that there are no delays of cc on my Linux machine.. I had some 
'missing reference' problems that I didn't fixed because I was only editing jsp files on that machine... Once I
included all libraries cc stoped being fast -it takes ~7 secs to popup.

For anyone trying to reproduce the problem, I suggest the following steps:

1) Create a new Web project.
2) Select the Visual Web JavaServer Faces Framework (use *.jsf URL mapping or else 'forwardToJSF.jsp' will not be generated)
3) Add JSTL 1.1 Library.
4) Add JSF 1.2 Library.
5) Open forwardToJSF.jsp file and paste the following lines under the <%@page directive:
	<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
	<%@ taglib prefix="f" uri="http://java.sun.com/jsf/core" %>
	<%@ taglib prefix="h" uri="http://java.sun.com/jsf/html" %>
	<%@ taglib prefix="w" uri="http://www.sun.com/webui/webuijsf" %>
6) Invoke cc by typing a '<' character in a blank line.

On my machine it took 14 seconds for cc to popup. 
Comment 31 Petr Jiricka 2008-01-25 08:12:55 UTC
Tomas Mysik is currently looking at JSP parser performance problems, adding him to cc.
Comment 32 Marek Fukala 2008-01-25 09:17:23 UTC
According to the latest comment I guess the problem can be with The TldLocationCache reparsing all jar files on the
classpath each time it is asked for them. May have something to do with Files' timestamps on windows. Reassigning to
Tomas Myslisk since he is supposed to work on the parser performance.
Comment 33 Tomas Mysik 2008-01-28 13:46:05 UTC
I'm looking at it.
Comment 34 Tomas Mysik 2008-01-28 13:48:10 UTC
Created attachment 55648 [details]
Profiler snapshot (open+paste+cc)
Comment 35 Tomas Mysik 2008-01-28 14:40:01 UTC
I'm not able to reproduce that the second cc takes the same time as the first one. Maybe Windows specific, I'm on 
Linux. Can someone verify this please? Thanks.
I will investigate more.
Comment 36 Tomas Mysik 2008-01-29 10:55:24 UTC
Adding David to CC because he can check this on Windows. Thanks David.
Comment 37 David Konecny 2008-01-30 04:10:51 UTC
I tested latest fragou's suggested steps and CC is visible immediately (<1sec).

Product Version         = NetBeans IDE 6.0 (Build 200711261600)
Operating System        = Windows Vista version 6.0 running on x86
Java; VM; Vendor        = 1.6.0_05-ea; Java HotSpot(TM) Client VM 1.6.0_05-ea-b04; Sun Microsystems Inc.
Comment 38 Tomas Mysik 2008-01-30 09:33:20 UTC
to fragou: could you please attach threaddump taken during the *second* cc? it would be very helpful, thanks
Comment 39 fragou 2008-01-30 12:54:32 UTC
Created attachment 55756 [details]
Thread Dump During 2nd CC
Comment 40 fragou 2008-01-30 13:07:07 UTC
Tomas, please also note that I couldn't reproduce the problem on Linux yesterday, the second CC is up immediately.
This is very strange because as I said last time it was performing the same as on Windows..
Is it possible this problem to be related with the JRE used by NetBeans? If so, how can I change this without re-installing?
Comment 41 Marek Fukala 2008-01-30 13:35:10 UTC
Just an idea - cannot it be caused by modification time of the jars in the future? If the timestamps algorith was
implemented incorrectly...
Comment 42 David Konecny 2008-01-30 19:38:21 UTC
re. "change JRE used by NetBeans" - edit netbeans_jdkhome property in netbeans\etc\netbeans.conf
Comment 43 Tomas Mysik 2008-01-31 23:05:09 UTC
to fragou:
Could you please send me the directory structure of your project (I mean listing of files in your project)? You can do 
this using e.g. "cd <project_dir> && find > listing" (on Linux). I have suspicion where could be the problem... 
Thanks.
Comment 44 fragou 2008-02-01 01:57:05 UTC
Tomas, I switched to JDK 1.5 and there is no change in performance...
I will send the folder tree of the test project I've suggested in a previous message because it's smaller than
the regular project I'm working on, so it will be more clear for you to check what you want.
Comment 45 fragou 2008-02-01 01:57:55 UTC
Created attachment 55886 [details]
Test Project Tree
Comment 46 Tomas Mysik 2008-02-01 09:37:51 UTC
Fragou, I'm going to prepare module for you with extended logging - I hope it will be ready on monday. Could you 
please attach your testing project? I could ask QE for trying to reproduce. Thanks.
Comment 47 fragou 2008-02-01 12:25:06 UTC
Ok Tomas,
I'm attaching the test project and wait for the module you said.
Comment 48 fragou 2008-02-01 12:26:03 UTC
Created attachment 55907 [details]
Test Web Project
Comment 49 Tomas Mysik 2008-02-07 10:42:18 UTC
Hi fragou, sorry for the delay - I'm going to attach module with improved logging.
Instructions:
- download development version of NB from http://bits.netbeans.org/download/trunk/nightly/latest/
- replace 'netbeans/enterprise5/modules/ext/jsp-parser-ext.jar' with the attached one
- start NB from command line 
using './netbeans -J-Dorg.netbeans.level=1000 -J-Dorg.netbeans.modules.web.jspparser_ext.WebAppParseSupport.level=500', 
ideally with clean userdir ('--userdir /tmp/cleannbuserdir')
- reproduce the delay during the second code completion
- attach messages.log file located in 'userdir/var/log/messages'

Thank you for helping us,
Tomas
Comment 50 Tomas Mysik 2008-02-07 10:43:28 UTC
Created attachment 56224 [details]
module with improved logging
Comment 51 fragou 2008-02-08 12:19:28 UTC
Hello again Tomas,

I followed you instructions and reproduced the problem. I invoked the CC a few times, saved the file and invoked
again and there is no deference in performance. I hope the log file I'm attaching will help you to investigate further.

Regards,
Chris(fragou)
Comment 52 fragou 2008-02-08 12:20:39 UTC
Created attachment 56344 [details]
Extended Log File
Comment 53 Tomas Mysik 2008-02-12 12:59:39 UTC
Hi Chris,
would it be possible to test that scenario once more please? I'll attach new version of the module (caching logic was 
completely rewritten but it's not tested enough yet).

Thanks,
Tomas.
Comment 54 Tomas Mysik 2008-02-12 13:00:30 UTC
Created attachment 56515 [details]
new version of module
Comment 55 Tomas Mysik 2008-02-12 13:03:49 UTC
Chris, I forgot: The problem I found in your messages.log was that the cache was not correctly created/verified. And 
so the code completion took so long for every time. It would be great if you were able to attach your messages.log 
file again after the testing of the new module version. Thanks.
Comment 56 fragou 2008-02-12 17:54:21 UTC
Hi Tomas,

I repeated the testing procedure with the new module and CC works like a charm! I also tested the normal project
I'm working on and CC worked just fine. For the test project there was no delays at all, and for the normal one -that
includes a lot of libraries, CC was slow only the first time invoked. I will attach the messages.log file after this
message.
One question: can I use this module with NetBeans 6.0? It would improve my daily work a lot.

Thank you,
Chris
Comment 57 fragou 2008-02-12 17:55:33 UTC
Created attachment 56546 [details]
Log File for Second Module
Comment 58 jessholle 2008-02-12 18:24:38 UTC
I too would *really* like to see this as a regular Update Center update for NB 6.0.
Comment 59 Tomas Mysik 2008-02-12 19:18:42 UTC
Hi Chris,
first of all - thank you :) but it's still work in progress. The module has to be heavily tested, from the log you 
attached I see that you only invoked cc and that's definitely not enough. Other areas which have to be tested are:
- functionality in Web project with custom build.xml
- changing class path (adding library, removing library)
- adding/changing/removing custom tld, tag files
- editing web.xml (changing tag library mappings)
- behaviour of the JSP editor in general - no regressions cannot be found

As you can see, it's a lot of work. It would be very helpful if you could help us :)

To your question about NB 6.0: hard to say because of areas mentioned above. Anyway you can try it - find that module 
in your NB directory, backup it and try to use the new one. Hope this help (and let us know :).

Thanks,
Tomas
Comment 60 fragou 2008-02-13 12:16:43 UTC
Hello Tomas,

Yesterday I replaced the module in NetBeans 6.0 with the new one and as far as I see, everything works normally. I've
opened my normal project and CC was performing very nice -I even noticed an improvement in page validation(or maybe this
is my idea). Today I reopened the project and got the same results. I think the cache is working right because when I
invoked CC the list appeared immediately, it didn't scan the classpath again.

Then I added a library to the project and after this I noticed a peak in CPU activity for a few seconds. Invoked the CC
and it was 1-3 seconds slower the first time with no delays in subsequent invocations. After removing the library same
thing happened.

Next thing I checked was to create a JSP file with XML syntax. When I tried to add the tag libraries to the <jsp:root>
element using the xmlns:x attribute, there was no CC with the list of available taglibs. When I do the same at a
standard JSP file using the <%@ tablib prefix="..." uri="..." %> directive, invoking CC inside the quotes of the uri
attribute brinks up a list with the aforementioned taglibs. This is not a performance issue but I thought it is good
to report. Anyway, as far as I seen CC performance of the new module is good with XML JSP files.

These are the tests I've made until now. Be sure that I will inform you if I find anything else. And I'm willing to help
in anyway I can. Feel free to give me instructions for anything you thing that will be helpfull. I can't promise
anything about response times though, because I'm quite a bit stressed lately.

Thanks a lot,
Chris
Comment 61 Tomas Mysik 2008-02-13 13:10:03 UTC
Hi Chris,
thanks a lot for your report. Actually I just pushed all the changes into trunk because I have similar feedback from 
our QE. So please if you find any bug, feel free to file an issue. Thanks.

This issue should be fixed by complete rewrite of caching strategy of tag libraries (changesets 62be113940b4, 
4367d68ca4ab and 0f9daacfcaf3).
Comment 62 Jindrich Sedek 2008-02-18 13:57:16 UTC
verified
Comment 63 Tomas Mysik 2008-02-18 15:10:01 UTC
Changesets for NB 6.0 backport:

4367d68ca4ab
62be113940b4
388a9220c4ca
0f9daacfcaf3
Comment 64 Tomas Mysik 2008-02-18 17:48:12 UTC
There's some deadlock in JSP parser - I have to look at it, please see issue #127672.
Honzo, what about its impact on NB 6.0 backport? Thanks.
Comment 65 Tomas Mysik 2008-02-18 19:06:57 UTC
Temporarily removing 'release601_fixes_candidate2' keyword because of deadlock in issue #127672. I will try to solve 
it tomorrow.
Comment 66 Tomas Mysik 2008-02-18 21:33:13 UTC
Returning the keyword.
Comment 67 Tomas Mysik 2008-02-19 16:31:37 UTC
Just FYI, issue #127672 should be fixed now.
Comment 68 rbalada 2008-03-07 18:09:13 UTC
revision 1.14.8.1
date: 2008/03/07 17:55:36;  author: rbalada;  state: Exp;  lines: +354 -518
IZ 123370 JSP editor VERY slow.
Integration contains also fix for issue issue 127762
Following changesets have been backported to release601_fixes branch in file
web/jspparser/extsrc/org/netbeans/modules/web/jspparser_ext/WebAppParseSupport.java
http://hg.netbeans.org/main?cmd=changeset;node=62be113940b4
http://hg.netbeans.org/main?cmd=changeset;node=388a9220c4ca
http://hg.netbeans.org/main?cmd=changeset;node=0f9daacfcaf3
http://hg.netbeans.org/main?cmd=changeset;node=7524db6aed85
http://hg.netbeans.org/main?cmd=changeset;node=4cffe70b2b73
http://hg.netbeans.org/main?cmd=changeset;node=4367d68ca4ab
http://hg.netbeans.org/main?cmd=changeset;node=0869473fbef6
http://hg.netbeans.org/main?cmd=changeset;node=5eb783048f20
This integration does not touch tests nor other files.
Comment 69 rbalada 2008-03-07 18:38:22 UTC
Correction of my previous comment (desc69): The integration in release601_fixes branch delivered also fix for issue
127672 "Frozen delete project action". The issue 127762 is about localization and has no relation (AFAIK) to this issue.
Comment 70 rbalada 2008-03-10 21:11:58 UTC
During testing of patch in release601_fixes branch was identified that there is new NPE, so I had to backport also
changeset http://hg.netbeans.org/main/rev/e0e7a718d9ad "Unused property removed" to fix that. 

File web/jspparser/extsrc/org/netbeans/modules/web/jspparser_ext/Attic/WebAppParseSupport.java revision 1.14.8.2 got
this change.