what project type? which panel in the properties dialog was on top?

I guess some of the panels in the dialog want to access java infrastructure but that one is busy elsewhere.

or it's just a general resource limitation problem where the CPU is busy and can't process the dialog showing fast 

I'm fairly sure the project was a web application project that I was using the context menu of.

I'm fairly sure it's not a simple CPU resource limit, as the workstation I'm using is a dual quad xeon (8 cpu).  now, 
whether java is imposing an artificial limit, I could not tell you.  

there could well be some blocking going on, and that is the point of the post.

the ide gave the appearance of being locked up.

the progress indicator stopped dead in it's tracks.

I would have thought that even if the appearance of the properties dialog was delayed due to blocking, that the screen 
updates to the ide should have continued to take place - ie: the cylon-esque progress/activity indicator for the scan 
at the bottom right should have kept going.

it would help if you had reproducible steps, thread dumps or anything that would help up track down the problem. The
current description is a bit vague.

anyway, reassigning to web, as probably one of it's panels is the culprit here and is calling java/gsf infrastructure in
AWT.

Created attachment 70993 [details]
thread dump

I was able to reproduce it: start NB; create a Web Project; open some NB project with bunch of its subprojects. Opening
NB project should cause long classpath scanning after IDE startup and in that time open project properties of the Web
Project. UI gets frozen for a while and as can be seen from attached thread dump it is caused by Struts framework
request to Java parser infrastructure.

There is couple of possible solutions. First one I would like to investigate is to check whether Struts framework could
be less aggressive and perhaps just check web.xml for Struts framework detection in a project? Would that be possible?
Other solution would be to call framework detection in background thread and show "loading..." in UI until that's
finished. Doable but considering that WebFrameworkProvider.isInWebModule() can be called frequently it should be as
quick as possible.

this is actually a P2 issue.

great work on reproducing the issue and getting a thread dump!

I'm not sure about P2 - in my instance the dialog is frozen for about 3-5 seconds and then everything works fine again.
Also it happens only if scanning is running. In that respect it is still a valid issue but more of a P3 IMO.

> to check whether Struts framework could be less aggressive and perhaps just check web.xml for Struts framework

In JavaServer Faces framework, it does only check "javax.faces.webapp.FacesServlet" as an existing "ServletClass". While
in Struts framework, it does not only check "org.apache.struts.action.ActionServlet" as an existing "ServletClass", but
also check whether there is any subtype of "org.apache.struts.action.ActionServlet" as an existing "ServletClass"!

Petr, what do you think? I agree the Struts check is more complete but it may face more performance issues! Besides, is
there any use cases that users implement their own ActionServlet?

This is very common usecase that org.apache.struts.action.ActionServlet is extended and such class is registered in
web.xml. So the check is correct and has to be there still. For javax.faces.webapp.FacesServlet we don't have to do the
same check, because the FacesServlet class is final, so nobody can extend this class. 

the reason I say it's a P2 issue is due to the description of P2's:

performance:

UI responsiveness of a feature breaking UI guidelines (100ms, 1s) 
Significant scalability problem 
AWT thread blocked by a task which could run on background 
No or inappropriate indication of progress of a running task 

I'm pretty sure in my particular instance, that there are not any struts derivative classes in the particular projects 
I'm working with, but there may be a use case where others are, and expect it to behave correctly.  I suppose this is 
the struts way of figuring out what controller classes are out there, rather than having them specifically called out 
or registered in a control file of some sort.  perhaps that's part of the struts contract - to discover the struts 
controller classes.

I have quite a few classes amongst about 18 projects, and it takes considerably longer in my case for the scanning to 
be completed.  The more classes there are, the longer it will take.

having this take place on a worker thread seems like a good idea as long as there isn't a dependancy on the result 
being available before the user has the opportunity to do something in the ide....

I will have a look how easy/difficult would it be fixing this on Web project side and calling
WebFrameworkProvider.isInWebModule() in a backgrdound thread. Considering we are close to code-freeze if fix is too
complicated it may not be fixed for 6.5. The fix has associated UI change in frameworks list being loaded on demand but
that should be acceptable despite being in UI freeze.

I have committed an improvement (details: http://hg.netbeans.org/main?cmd=changeset;node=791bb0f079e8) from the Struts
module: When there is NO servlets in web.xml, should not call JavaSource.runUserActionTask, returns null immediately.

This will make David's test case no longer reproducible! Good to many users' environment, bad to our further test. But
we can make it reproducible again by changing David's reproducible steps: 'create a web project with JSF framework'
instead of just a web project without any framework. Then the test web project will have non-zero length servlets in the
web.xml and then causes the delay we have seen.

David, since I cannot easily find further improvement in Struts, at least for 6.5 without making big change, I agree
that the UI post needs to be done from the web project layer. I think we may decrease it to P3 after my Struts
improvement, especially for the need of changing UI.

For unknown reason, the issue changed the platform wrongly!

potingwu, that will help in cases where user does not have any servlet. I would argue though that it will be minority of
cases. You cannot anything useful without servlet in web app.

I think I can slightly improve the situation as well with a fix in the web project. I'm working on it right now.

Fixed locally as 1bda3d0ec086. Loading of frameworks is done in background thread and text "Loading..." is shown in
Frameworks panels in project properties if scanning is running on background.

Integrated into 'main-golden', will be available in build *200810031107* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/791bb0f079e8
User: potingwu@netbeans.org
Log: Improve Issue#148786, P2, [65cat] ide freezes when asked for project properties when project scanning is already underway.
When there is NO servlets in web.xml, should not call JavaSource.runUserActionTask, returns null immediately.

thank you!  that should help quite a bit.

No freeze observed. Verified.

Product Version: NetBeans IDE Dev (Build 200811240201)
Java: 1.6.0_10; Java HotSpot(TM) Client VM 11.0-b15
System: Linux version 2.6.27-7-generic running on i386; UTF-8; en_US (nb)