Integrated into 'main-golden', will be available in build *201004220200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/6b47a8a9071b
User: pjiricka@netbeans.org
Log: #176818 - better diagnostics

Now I also found the following in my log file. Denis, could you please investigate? Can this be fixed based on this information? Or is there nothing that can be done about it?

WARNING [org.netbeans.modules.parsing.impl.TaskProcessor]: ParserManager.parse called in AWT event thread by: org.netbeans.modules.j2ee.dd.impl.ejb.annotation.EjbJarMetadataModelImpl.runReadActionWhenReady(EjbJarMetadataModelImpl.java:106)

WARNING [org.netbeans.modules.parsing.impl.TaskProcessor]: ParserManager.parse called in AWT event thread by: org.netbeans.modules.j2ee.dd.impl.webservices.annotation.WebservicesMetadataModelImpl.runReadActionWhenReady(WebservicesMetadataModelImpl.java:105)

WARNING [org.netbeans.modules.parsing.impl.TaskProcessor]: ParserManager.parse called in AWT event thread by: org.netbeans.modules.j2ee.dd.impl.web.metadata.WebAppMetadataModelImpl.runReadAction(WebAppMetadataModelImpl.java:132)

WARNING [org.netbeans.modules.parsing.impl.TaskProcessor]: ParserManager.parse called in AWT event thread by: org.netbeans.modules.web.jsf.impl.metamodel.JsfModelImplementation.runReadActionWhenReady(JsfModelImplementation.java:105)

There are many places when various J2EE models are called in the AWT thread.
First of all : this is client decision . And it is really too hard to find
exact place where such call is performed.

But I don't see an issue .
EACH model access is done via Java source lock. But it doesn't mean that 
such call leads to index rescanning ( it could be but each such case should 
be identified separately ). 

Model do a caching of its objects. So usually model access doesn't invoke time
consuming calculation but just retrieving objects from cache.
On the same time model requires to be locked to avoiding access from different 
threads.

So the original bug description is not a bug. This is just warning which 
notifies that there is a call which COULD be a problem. But it doesn't mean
that this is ALWAYS a problem. Otherwise the warning should be changed 
on ERROR or even throw an exception.

So please provide exact problem description or steps to reproduce .

I agree we probably need more information to properly evaluate. E.g. which exact client is calling it, whether it really needs results in AWT immediately, and how long does the operation really take. I also assume that if there is a real performance problem, it would be reported as a "slowness detected" report with real performance data. I am cc'ing Tomas so he can confirm/clarify.

>I also assume that if there is a
>real performance problem, it would be reported as a "slowness detected" report
>with real performance data.

Totally agree.

The warning is rather informative to prevent clueless programming. The ParserManager.parse does parsing and possible types resolution (if required by caller) which is both CPU + IO bound. The parsing requires reading of the file (if not already opened in editor) + parsing O(sizeof(file)) - this is rather fast and takes ~ 100 ms. The analyze phase is much more IO bound and complexity depends on the number of referenced types. For classes with big closure it may takes seconds. The warning informs developer that (s)he should not do it (if there is way how to do it asynchronously). But there are places where it's inherently impossible not to call the PM.parse from AWT thread.

If it's impossible to rewrite the call to be out of AWT or the rewrite is expensive you can keep it. The warning is displayed only in dev builds (in builds where assertions are enabled).

Thank you Tomas for clarifying this.