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 210547

Summary:	Scanning blocks with compile error
Product:	javaee	Reporter:	Exceptions Reporter <exceptions_reporter>
Component:	Persistence	Assignee:	Sergey Petrov <sj-nb>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	sdedic, sj-nb
Priority:	P3
Version:	7.1
Hardware:	All
OS:	All
Issue Type:	DEFECT	Exception Reporter:	186560
Attachments:	stacktrace

Description Exceptions Reporter 2012-04-02 13:56:55 UTC

This issue was reported manually by sdedic.
It already has 1 duplicates 


Build: NetBeans IDE 7.1.1 (Build 201203012225)
VM: Java HotSpot(TM) 64-Bit Server VM, 22.0-b10, Java(TM) SE Runtime Environment, 1.7.0_02-b13
OS: Windows 7

User Comments:
GUEST: I have 3  Hashmaps
HashMap<String, SummaryStatistics> ...
which produce a compile error as they are later referred to as 
HashMap<String, s.th.else>
Sure, this produces a compile error which is okay.
But during refactoring, the IDE sometimes scans and pretty lags




Stacktrace: 
java.lang.Exception: Scan canceled.
   at java.lang.Thread.getStackTrace(Thread.java:1567)
   at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:74)
   at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:67)
   at org.netbeans.modules.parsing.api.indexing.IndexingManager.addIndexingJob(IndexingManager.java:430)
   at org.netbeans.modules.parsing.api.indexing.IndexingManager.refreshIndex(IndexingManager.java:178)
   at org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges.run(IncorrectErrorBadges.java:172)

Comment 1 Exceptions Reporter 2012-04-02 13:56:58 UTC

Created attachment 117662 [details]
stacktrace

Comment 2 Sergey Petrov 2012-04-10 09:34:57 UTC

Any reasons why it was filed for persistence?
I see some exceptions in persistence, but not sure it's related. Slowdown may be caused by exceptions logging also, may it have sense to cut some part of ex ceptions from annotation processors? May be just message on INFO level and show full dump in FINE case?

Comment 3 Svata Dedic 2012-04-10 09:39:19 UTC

Why to reassign ? The erroneous annotation processor is here (see logs at http://statistics.netbeans.org/exceptions/exception.do?id=569891):


java.lang.RuntimeException: javax.annotation.processing.FilerException: Attempt to recreate a file for type de.intelliad.db.intellibo_login_temp.RawTrackingImpressions_
     at org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor.process(eclipselink-2.3.0.jar:407)
     at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(javac-impl-nb-7.0-b07.jar:827)

The proper fix is not to mask out errors from annotation processors, but to actually work around them or solve them. The performance penalty is paid at the time of exception throw, when Stacktrace[] elements are populated, not so much when logging such an exception. Also note that aborted compilation probably causes some processing to be restarted, so the exception is unwanted in the first place.

Comment 4 Sergey Petrov 2012-04-10 09:45:25 UTC

it's user configuration error then, annotation processor just do not support generation of entities from several pu in one place, but we shouldn't be affected so much by user errors, even if persistence wizards will add subpackage automatically user will be able to create pu manually or use persistence.xml from another projects etc and in this case ap will produce these traces. I suppose it may cause problems as logging to message.log may be time consuming and it's not "hidding" to log less especially as it';s not severe(I hope) for nb itself.

Comment 5 Sergey Petrov 2012-04-10 09:47:08 UTC

ok, miss logging may not cause much penalty, but it still impossible to have no fix all cases wich may cause ap to throw exceptions (on nb side)

Comment 6 Sergey Petrov 2012-04-10 09:49:21 UTC

Ok, as part fix, the best I see not is to show warning badge either on project level or on persistence.xml level if there are more then one pu and no usage of subpackage and annotation processing is turned on. Then it may be reassigned back to persistence area, feel free.

Comment 7 Tomas Zezula 2012-04-10 13:57:53 UTC

The reason is:

at java.lang.Thread.getStackTrace(Thread.java:1567)
        at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:74)
        at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:67)
        at org.netbeans.modules.parsing.api.indexing.IndexingManager.addIndexingJob(IndexingManager.java:430)
        at org.netbeans.modules.parsing.api.indexing.IndexingManager.refreshIndex(IndexingManager.java:178)
        at org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges.run(IncorrectErrorBadges.java:172)
        at org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges.run(IncorrectErrorBadges.java:70)
        at org.netbeans.modules.java.source.JavaSourceAccessor$CancelableTaskWrapper.run(JavaSourceAccessor.java:324)

The errors come from EL, the waring persistence.xml is good. I can even filter out the errors generated by AP (EL) from the check. Will it help to you? If so, I can do it, just reassign back to me (java/source/tzezula).
Thanks

Comment 8 Sergey Petrov 2012-04-10 14:30:36 UTC

ok, will try first with warning implementation.

Comment 9 Sergey Petrov 2012-04-20 08:08:34 UTC

it's also a duplicate of issue 183779, and if compile on save produce this ouput, usual compilation should fail also. 183779 also mention subpackage automatic addition as a way to handle on nb side.

*** This bug has been marked as a duplicate of bug 183779 ***