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.
| Summary: | Refactoring is frozen at "Usage" step if ap in editor enabled | ||
|---|---|---|---|
| Product: | javaee | Reporter: | Sergey Petrov <sj-nb> |
| Component: | Persistence | Assignee: | Sergey Petrov <sj-nb> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dbalek, dkonecny, dstrupl, pjiricka, tzezula |
| Priority: | P1 | ||
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
log with thread dump
screen Test web project Eclipselink patch |
||
|
Description
Sergey Petrov
2010-04-05 10:13:35 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. 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. Thanks, will retry tomorrow. Have you tried New|Entity Class instead of Customer (if I got it right with New |Entity from DB)? Even with New Entity Class (Persistence/Entity Class) works fine for me. Created attachment 96851 [details]
log with thread dump
start ide, create all, refactor, thread dump, cancel refactor, close ide in log.
Created attachment 96852 [details]
screen
still reproducible, tried with jdk5 and jdk6 source levels 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 Is there any sense to file an issue against eclipselink? 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. Created attachment 96929 [details]
Test web project
The test web project. Ant compile hangs javac in the eclipselink.
Created attachment 96930 [details]
Eclipselink patch
The patch which fixes the live lock.
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. Thanks 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. 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. 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. 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? 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. https://bugs.eclipse.org/bugs/show_bug.cgi?id=308616 filed, looks like I can't file P1 issue and can affect only severity. http://hg.netbeans.org/web-main/rev/d0457fc90895 http://hg.netbeans.org/web-main/rev/d2d61da13f68 model jar is removed, but may not propagate to beta as it may be late http://hg.netbeans.org/web-main/rev/96c734d84103 http://hg.netbeans.org/web-main/rev/e8fa28b44204 remove ap registration in project properties need to port to beta to remove javac freeze as a default behavior in nb. http://hg.netbeans.org/release69_beta/rev/89f39c21cf51 moved to beta. canonocal processor isn't added by default for now, closing the issue, will need to verify later after canonical readdition. 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? 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. |