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.
NetBeans IDE Dev (Build 20070424-0751) 1.6.0_02-ea; Java HotSpot(TM) Client VM 1.6.0_02-ea-b02 Windows XP version 5.1 running on x86 en_GB (nb); Cp1252 dual core Description: ============ have empty IDE with clear userdir and try to create more than one JDA with db connection (model table - textfields). Results are: form is corrupted and plenty of exceptions are thrown note: this issue is mainly reproducible on windows platform. On linux, the rate of occurrences is lower. Restart didn't help me ...
The exceptions are thrown because the generated entity cannot be found in the model. It seems to be related to issue 101909. Reassigning to j2ee/persistence for evaluation. According to janie's report the steps to reproduce are: 1. Invoke New Project wizard for Java Desktop Application (in General category). 2. Select Database Application shell on the next page. 3. Select DB connection to GlassFish sample project on the third page. 4. Select CUSTOMER table. 5. Press Next and and then Finish. Repeat steps 1-5. several times: after several repetitions the generated entity will not appear in the model and the creation of the project will fail.
This issue is caused by the model not working properly for a project not opened in the UI (that is, whose classpath is not registered in GlobalPathRegistry), because Retouche gives no contracts for such classpaths. The right fix is a cooperation between Retouche, the model and the form editor, and is too tricky for M9. As a workaround, I will introduce a system property which, when true, will cause the model to avoid relying on events and initialize from scratch whenever invoked. This issue will then need to be waived for M9.
Created attachment 41700 [details] System property for turning off events
Please test the attached diff by starting the IDE with -J-Dnetbeans.metadata.model.volatile=true
Patch committed to trunk, with the difference that the netbeans.metadata.model.volatile is on by default. Checking in src/org/netbeans/modules/j2ee/metadata/model/api/support/annotation/AnnotationModelHelper.java; /cvs/j2ee/metadata/support/src/org/netbeans/modules/j2ee/metadata/model/api/support/annotation/AnnotationModelHelper.java,v <-- AnnotationModelHelper.java new revision: 1.4; previous revision: 1.3 done Checking in src/org/netbeans/modules/j2ee/metadata/model/api/support/annotation/PersistentObjectManager.java; /cvs/j2ee/metadata/support/src/org/netbeans/modules/j2ee/metadata/model/api/support/annotation/PersistentObjectManager.java,v <-- PersistentObjectManager.java new revision: 1.7; previous revision: 1.6 done
Diff: http://www.netbeans.org/source/browse/j2ee/metadata/support/src/org/netbeans/modules/j2ee/metadata/model/api/support/annotation/AnnotationModelHelper.java?r1=1.3&r2=1.4 http://www.netbeans.org/source/browse/j2ee/metadata/support/src/org/netbeans/modules/j2ee/metadata/model/api/support/annotation/PersistentObjectManager.java?r1=1.6&r2=1.7
The patch seems good. It does not influence anything else then the Form module, so it should not introduce any regression.
Reverting back mbalin's change. JDA = Java Desktop Application JPA = Java Persistence Architecture/API
*** Issue 102161 has been marked as a duplicate of this issue. ***
I tested this patch for two hours. The main issue, means that was not possible to create more then two db JDAs in IDE, seems to be solved and now I am able to create a plenty of these projects without forms destroying. IMHO: patch could be merge to M9 branch But I have to say that this patch doesn't fix this issue at all. For now I am not able to find out exact reproducible usecase :( but the result of it is the same - corrupted form and a plenty of thrown exceptions. Steps look mostly like this: 1. Create JDA with connection to db - table customer (detailed model: table - textfield) 2 then create new Master/detailed form in new package with connection to the same table but with detailed model: table - table 3. do the same described in step no.2 and create another form with the same properties I created always at least two or three projects like this and do some actions like - build, delete some of the projects or create another form After a while when I tried to create another new JDA project, above described results occurred and creation failed.
correction: But I have to say that this patch doesn't fix this issue *at all* Sorry, I chose wrong expression. I wanted to say that patch doesn't resolve issue completely.
Integrated in the release60-m9 branch. Checking in src/org/netbeans/modules/j2ee/metadata/model/api/support/annotation/AnnotationModelHelper.java; /cvs/j2ee/metadata/support/src/org/netbeans/modules/j2ee/metadata/model/api/support/annotation/AnnotationModelHelper.java,v <-- AnnotationModelHelper.java new revision: 1.3.2.1; previous revision: 1.3 done Checking in src/org/netbeans/modules/j2ee/metadata/model/api/support/annotation/PersistentObjectManager.java; /cvs/j2ee/metadata/support/src/org/netbeans/modules/j2ee/metadata/model/api/support/annotation/PersistentObjectManager.java,v <-- PersistentObjectManager.java new revision: 1.6.2.1; previous revision: 1.6 done
Regarding the other issue you are encountering, I guess we'll have the chance to address it together with the proper fix. Downgrading to P2.
In today's build there this patch doesn't work at all I increased the priority to P1
I went through recent changes in code base and I have found a fix of issue 102597 that seems responsible for the fact that the patch no longer works. When I had a revision 1.51 of RepositoryUpdater.java then the patch worked. When I updated to revision 1.52 then the creation of JDA project failed.
I can reproduce in an all-in-one nightly build of M9. It seems the scan of the project's classpath doesn't take place (or finish), so ClassIndex doesn't know about Customer.java (it actually doesn't even seem to know about TopLink). I'm just checking out M9 and will try to play with RepositoryUpdater. But it seems the issue will go to Tomas after all.
I can reproduce the problem in trunk after updating RepositoryUpdater. Tomasi, can you please have a look at it?
OK, I am looking at it. It's sure that it's caused by fix of issue #102597. The existingSourceLevel is null. But I need to say again that it's neither problem of the j2ee model nor the fix but the form editor which misuses it.
> the form editor which misuses it We would be happy to change our implementation if you can provide us a reasonable alternative, but AFAIK there is no alternative. So, please, don't blame us.
OK. I've went through the code and I have to agree with the fix of the issue #120597. The problem is really on the form editor side and should be fixed there, the feature worked only thanks to the fact that the unknown classpath was asynchronously (=> race condition) rescanned by JavaSource when it found that the source level differs from the previous one (null). Probably reassign to form editor.
Tomas, we had a meeting about this issue 2 days ago and we agreed on the current solution. If you today insist on the fact that form editor does something incorrectly, please, propose an alternative solution.
I don't agree that we had such a conclusion. As far as I remember the conclusion was that it works by lack. My guess was 1:100 and Andrei tries to do an workaround which should be tried but may not work. Now we see that the workaround doesn't work. The conclusion was that either a new API will be needed or form should be redesigned to use the current API properly (not in M9).
Please, don't start a flame war about feelings about our meeting and about guiltiness of me, you or Andrei. I would prefer to stay on a constructive side. I just would like to emphasize that it doesn't help us at all to say just that form editor does something incorrectly. I would like to hear what should we do differently. I guess that you know our use case very well. So, if you don't like how it is coded by now, please, give us your valuable ideas how it should be done in a different way.
One possible but ugly solution which may be tried is to register the nonexistent classpaths into GlobalPathRegistry and unregister them before opening project. If you send me a source name where the wizard is located I can try it.
Probably MasterDetailWizard.instantiate() in form/j2ee. I haven't tried that yet. But I tried adding the source classpath to GPR just for the purpose of the entity generation, and then removed it. That caused the entity to dissapear from ClassIndex (it had been there before).
Created attachment 41832 [details] Diff file
I installed the patch into 6.0 M9 build 04270000 and all worked fine with one exception. IDE started with fresh user dir (removed before start), 1st db application project created and when wizard closed I've got PersistanceException see attachement. It was not alone. After that I removed project (Remove action) and continued creation of DB apps successfully. No more exceptions thrown. Exception is attached.
Created attachment 41845 [details] PersistenceException
Additional note to fresh userdir & DB project creation. Exception does not happen always in this scenario. Only once with 3 fresh userdirs tests. It tooks long: 83 seconds from hitting Finish button to moment when form is opened and all dialogs are gone. Centrino Core 2 Duo 2 Ghz, 2GB RAM.
Created attachment 41846 [details] Updated diff
Latest patch update with longer timeout seems to be OK. I cannot reproduce it. Tried 3x to start with fresh user dir.
I tested form with last patch and gandalfpersistanceexc exception occurred only once. I am not able to described an exact steps but it happened during testing, so I haven't clear userdir. (in IDE there were cca 6 database JDA and 2 simple Java Application projects) But it happened only once and then I was able to continue and create next JDA with db. One notice: when Project with corrupted form is deleted, another exception occur but it could be consequences of previous fail StackTrace: =========== SEVERE [global] org.openide.filesystems.FileStateInvalidException: MasterFileObject@1e7e4d0[C:/Documents and Settings/Admin/Local Settings/Temp/tests-Admin/org.netbeans.qa.form.OpenTempl_defaultPack/DesktopApplicatio n2/src] at org.openide.loaders.DataObject.find(DataObject.java:451) Caused: org.openide.loaders.DataObjectNotFoundException: MasterFileObject@1e7e4d0[C:/Documents and Settings/Admin/Local Settings/Temp/tests-Admin/org.netbeans.qa.form.OpenTempl_defaultPack/DesktopAppl ication2/src] at org.openide.loaders.DataObject.find(DataObject.java:471) [catch] at org.netbeans.modules.openide.loaders.DataObjectEncodingQueryImplementation.getEncoding(DataObjectEncodingQueryImplementation.java:41) at org.netbeans.api.queries.FileEncodingQuery.getEncoding(FileEncodingQuery.java:70) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.parseFiles(RepositoryUpdater.java:1326) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.updateFolder(RepositoryUpdater.java:1473) at org.netbeans.modules.java.source.usages.RepositoryUpdater$CompileWorker.access$400(RepositoryUpdater.java:867)
Honza will integrate the attached patch. Thanks Honzo, my connection is quite slow and checkout of m9 will take long time.
Created attachment 41850 [details] StackTrace
The last attached exception are completely unrelated to this issue? When the gandalfpersistenceexc was thrown was it after 3 minutes timeout or shorter time? If it was after shorter time it is not related to this patch and is caused by another model problem.
yes, you are right, it doesn't fail due to a timeout. Project was created with corrupted form in one minute, not longer...
In this case it is another model or events issue not related to this fix. When the project was created in less then 3 minutes then all classpaths were scanned and Andrei should know about all classes. Anyway the patch fixed the most important problem causing gandalfpersistenceexc in nearly all cases.
The attached patch has been applied in trunk: http://form.netbeans.org/source/browse/form/swingapp/src/org/netbeans/modules/sw ingapp/templates/NewAppWizardIterator.java?r1=1.2&r2=1.3
The patch looks good - a reasonable solution in current situation. Please integrate to m9 branch.
The attached patch has been applied to release60-m9 branch: src/org/netbeans/modules/swingapp/templates/NewAppWizardIterator.java new revision: 1.2.2.1; previous revision: 1.2 Closing as fixed. The problem mentioned by janie seems to be unrelated to this issue. If you are still able to reproduce it, please, fill a separate issue.
verified on NetBeans IDE Dev (Build 070430) 1.6.0; Java HotSpot(TM) Client VM 1.6.0-b105 Windows XP version 5.1 running on x86 en_GB (nb); Cp1252 I try to investigate how to reproduce previous described issue.