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 183473 - Refactoring is frozen at "Usage" step if ap in editor enabled
Summary: Refactoring is frozen at "Usage" step if ap in editor enabled
Alias: None
Product: javaee
Classification: Unclassified
Component: Persistence (show other bugs)
Version: 6.x
Hardware: All All
: P1 normal (vote)
Assignee: Sergey Petrov
Depends on:
Reported: 2010-04-05 10:13 UTC by Sergey Petrov
Modified: 2010-04-09 17:00 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

log with thread dump (79.09 KB, text/plain)
2010-04-07 09:46 UTC, Sergey Petrov
screen (205.94 KB, image/png)
2010-04-07 09:47 UTC, Sergey Petrov
Test web project (12.79 KB, application/octet-stream)
2010-04-08 20:54 UTC, Tomas Zezula
Eclipselink patch (793 bytes, patch)
2010-04-08 20:55 UTC, Tomas Zezula
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Petrov 2010-04-05 10:13:35 UTC
-create entity (new|entity)
-create java class
-extend from the entityand add @Entity annotation
-create second class
-extend from the entity and add @Entity
-refactor entity class name
It takes forever but if ap in editor support is switched off all is completed in a second. If I switch back, all will be completed in a second also, but if I'll add new one class and extend and add @Entity, refactoring will stop at  "Usage" step.
Comment 1 Tomas Zezula 2010-04-06 13:31:10 UTC
I've tried and it works fine for me. I am building current build to retest it with recent sources.
I've created a web app, add PU, add a Customer entity. Created 2 subclasses of the Customer annotated with @Entity and renamed the Customer to Customer2. The refactoring ended successfully.
Comment 2 Tomas Zezula 2010-04-06 16:29:33 UTC
I am not able to reproduce it even with current build. :-(
I did what I've described above and everything works fine.
Sergey, can you recheck it with new build? If you still have this problem please reopen this issue and add several stack traces. Thanks very much.
Comment 3 Sergey Petrov 2010-04-06 16:52:16 UTC
Thanks, will retry tomorrow.
Have you tried New|Entity Class instead of Customer (if I got it right with New
|Entity from DB)?
Comment 4 Tomas Zezula 2010-04-06 18:23:48 UTC
Even with New Entity Class (Persistence/Entity Class) works fine for me.
Comment 5 Sergey Petrov 2010-04-07 09:46:52 UTC
Created attachment 96851 [details]
log with thread dump

start ide, create all, refactor, thread dump, cancel refactor, close ide in log.
Comment 6 Sergey Petrov 2010-04-07 09:47:36 UTC
Created attachment 96852 [details]
Comment 7 Sergey Petrov 2010-04-07 09:49:02 UTC
still reproducible, tried with jdk5 and jdk6 source levels
Comment 8 Tomas Zezula 2010-04-08 14:32:01 UTC
Finally I am able to reproduce it.
Unfortunately it's not a deadlock, it's livelock in the eclipselink.
I will try to find some hack how to solve it (if the eclipselink will ask javac, but if not it's unsolvable in the java.source).
The problem is never ending loop in the: EntityAccessor.discoverMappedSuperclassesAndInheritanceParents
Comment 9 Sergey Petrov 2010-04-08 17:07:57 UTC
Is there any sense to file an issue against eclipselink?
Comment 10 Tomas Zezula 2010-04-08 20:53:10 UTC
Yes, It's the only possible fix. I am not able to workaround it in the java infrastructure as the eclipselink builds it's own model from elements and I cannot detect the cycle in the calls to the javac.

The problem can be reproduced using ant form the command line, I will attach the project (web app, you need to resolve broken refs and then you can try ant clean; ant compile which hangs the javac).

I will also attach a patch to eclipselink which fixes the problem. The thing is that when the entity extends nonexisting class (typo in extends or not finished name) the eclipselink gets "void type". The parent of "void type" is "void type" and the eclipselink cycles while the type != j.l.Object.

The deadlock happened in the following way:
When you was typing the extends the eclipselink hanged the compiler and when you invoked the refactoring it was waiting until the compiler becomes ready.

In addition to this Dusan is going to add additional method into APQuery.isAnnotationProcessorEnabledInEditor. So we will have 4 states:
1) AP are switched off
2) AP are switched on in ant but not in editor
3) AP are enabled in the editor
4) AP are partially enabled in editor - a NEW state. Where AP are not called when you type in editor but only when you save the file. This will be probably the default, this makes the probability of unknown super class smaller. I will let you know when this will be done.
Comment 11 Tomas Zezula 2010-04-08 20:54:17 UTC
Created attachment 96929 [details]
Test web project

The test web project. Ant compile hangs javac in the eclipselink.
Comment 12 Tomas Zezula 2010-04-08 20:55:44 UTC
Created attachment 96930 [details]
Eclipselink patch

The patch which fixes the live lock.
Comment 13 Tomas Zezula 2010-04-08 21:02:28 UTC
It will be great if you can create the issue to eclipselink.
I don't know if we should try to workaround it for NB. Is far as I remember you are already adding one jar having the processor registration in the META-INF/services, right? If so we can put also the patched class into it and place the jar on the first place in the Eclipselink library. But I am not sure if we should do it.
Comment 14 David Konecny 2010-04-08 21:40:28 UTC
Sergey, I talked with PetrJ and Tomas and we have agreed that:

* P1 issue should be filed for EclipseLink with patch from Tomas attached (and the reproducible case)

* for NB69Beta EclipseLink annotation processor should be disabled, that is it should not be automatically added to newly created JPA project. Justification: the livelock can happen too often and on the other hand there is not that many users who are already using JPA Criteria API and need JPA meta model classes. These users should still be able to enable this annotation processor via project properties (can you confirm that please?) but the livelock from EL will be their problem to deal with.

Could you please do both of these items? Thanks. Hopefully for NB FCS the problem will be fixed in EL.
Comment 15 Sergey Petrov 2010-04-09 06:51:23 UTC
I'll create an issue for eclipselink today,I'm not sure if it can be fixed fast as there was RC1 for 2.02 on Mar 24, but if eclipselink team will agree it's P1, may be it can be fixed fast.

Disabling of metamodel generation ean we need to remove META-INF regstration and user will need to add class manually. We can't just disable ap in editor support by default as there will e an issue with run/deploy actions.
Comment 16 Tomas Zezula 2010-04-09 06:58:53 UTC
Yes, Sergey is right. If we disable the run AP in editor, Compile On Save will not work.
Dusan is working on the switch which disables AP in editor but still it will run after save, so CoS will work.
Another solution is the classpath prepend, not sure if it's legal.
Comment 17 Petr Jiricka 2010-04-09 07:57:31 UTC
I must say I don't understand why we can not disable the AP by default (by removing the META-INF registration). This was the situation in 6.8, right? So can we just revert to the 6.8 behavior for beta?
Comment 18 Sergey Petrov 2010-04-09 08:43:32 UTC
Yes, we can to revert changes or part of changes related top metamodel generation.
I.e. remove extra jar, disable addition of canonical processor to ap list.
May be corresponding issue need to be reopened but may be can be downgraded to p3 as we have support for ap now and iuser can always add ap name manually.
Comment 19 Sergey Petrov 2010-04-09 08:52:20 UTC filed, looks like I can't file P1 issue and can affect only severity.
Comment 20 Sergey Petrov 2010-04-09 08:58:20 UTC

model jar is removed, but may not propagate to beta as it may be late
Comment 21 Sergey Petrov 2010-04-09 10:55:53 UTC
remove ap registration in project properties
Comment 22 Sergey Petrov 2010-04-09 12:28:41 UTC
need to port to beta to remove javac freeze as a default behavior in nb.
Comment 23 Sergey Petrov 2010-04-09 13:57:51 UTC
moved to beta.
canonocal processor isn't added by default for now, closing the issue, will need to verify later after canonical readdition.
Comment 24 David Strupl 2010-04-09 15:51:27 UTC
Do I understand it correctly that now the situation is that if the users add the AP manually they might get the livelock? I would not call that "their problem" ;-) 

But I agree that this might not be beta blocker any more. BTW should this (or some other) bug report stay opened so that we know that something should happen before FCS? Also if the problem is solved in EL we might revert this fix so the AP is on by default for FCS, right?
Comment 25 Sergey Petrov 2010-04-09 17:00:03 UTC
I'll reopen #178108 to track and lower to P3 as it's now much easier to generate metamdel by just adding canonical processor in options.