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.
When i create persistence unit the persitence.xml is created but is empty, it's not generated. Found in trunk build #200702121900 1. create entity classes from db 2. create persistence unit 3. look at the persistence.xml => it's empty
I'm able to reproduce this, though occasionally it seems to work. The problem is that a wrong kind of DataObject (an XmlDataObject in this case) is being associated with the persistence.xml file, even though the loader for the correct data object, PUDataObject, is configured to be loaded before regular XMLDataObject. Perhaps somehow caused by the moving of the persistence module to the ide cluster.
Fixed in trunk. Need to revisit when issue 95675 gets resolved. Checking in unit/PUDataObject.java; /cvs/j2ee/persistence/src/org/netbeans/modules/j2ee/persistence/unit/ PUDataObject.java,v <-- PUDataObject.java new revision: 1.3; previous revision: 1.2 done Checking in unit/PUDataLoader.java; /cvs/j2ee/persistence/src/org/netbeans/modules/j2ee/persistence/unit/ PUDataLoader.java,v <-- PUDataLoader.java new revision: 1.3; previous revision: 1.2 done Checking in provider/ProviderUtil.java; /cvs/j2ee/persistence/src/org/netbeans/modules/j2ee/persistence/provider/ ProviderUtil.java,v <-- ProviderUtil.java new revision: 1.11; previous revision: 1.10 done
I'm sorry, I can't agree with this issue being closed. The "fix" is just a crude hack, so downgrade to P3 if you wish, as there is no user impact, but please leave it open. What is the cause of this issue? This used to work in 5.5, right? Which change caused it to stop working? Issue 95675 does not give any clues, it just seems to imply that the DataObject is recognized before the contents of persistence.xml is generated. What triggers the recognition?
As I wrote in issue 95675 it works in 5.5. I don't know what change made it stop working, especially since the current behaviour is not persistence.xml specific (you can reproduce it with web.xml as well as stated in issue 95675). In short what happens is that when a file is created the DataObject#find gets invoked and since the file has no content at this point, it gets associated with an incorrect data object (with an XmlDataObject instance in this particular case), because many data loaders try to recognize the file based on its content, not only on its extension. That is the case, as you know, for the PUDataLoader as well. After that, when the DataObject#find is invoked again (this time with the fully constructed file), the data object associated earlier with the file is got from a pool and the correct loader no longer gets a chance to recognize the file. If you think that something wrong is being done in j2ee/persistence (and j2ee/ ddloaders), please let me know. Otherwise I don't consider this to be a bug in j2ee/persistence but a limitation in the FS APIs.
I doesn't seem to me j2ee/persistence does anything wrong. But I wouldn't say this is a limitation of the FS API without some evidence either. Best if you could find out what triggers the first DataObject.find() call. Can you obtain a strack trace showing the recognition of a persistence.xml file by XMLDataLoader? If yes, please attach it here.
Here's the stack trace for the first invocation of the find method (at this point the created file has no content): DataObject.find line: 450 LocalHistory.isEditable line: 112 LocalHistory.isManaged line: 101 LocalHistoryVCSInterceptor.accept line: 239 LocalHistoryVCSInterceptor.beforeCreate line: 150 FilesystemInterceptor$DelegatingInterceptor.beforeCreate line: 309 FilesystemInterceptor.createSuccess line: 138 ProvidedExtensionsProxy.createSuccess line: 126 MasterFileObject.createData line: 432 FileUtil.copyFileImpl line: 224 FileObject.copy line: 98 MultiFileObject.copy line: 1231 MultiFileObject.copy line: 1231 FileUtil.copyFile line: 285 And for the second invocation, when the file is fully constructed: DataObject.find line: 450 LocalHistory.isEditable line: 112 LocalHistory.isManaged line: 101 LocalHistoryVCSInterceptor.accept line: 239 LocalHistoryVCSInterceptor.afterCreate line: 162 FilesystemInterceptor$DelegatingInterceptor.afterCreate line: 319 FilesystemInterceptor.fileDataCreated line: 148 FCLSupport.dispatchEvent line: 75 FileObject$ED.dispatch line: 891 EventControl.invokeDispatchers line: 181 EventControl.exitAtomicAction line: 155 EventControl.runAtomicAction line: 100 FileSystem.runAtomicAction line: 471 ProviderUtil.createPersistenceDDFile line: 539 ProviderUtil.getPUDataObject line: 524 As you suspected, with the local history module disabled the method isn't invoked with an empty file and things work as expected from the j2ee/ persistence point of view.
Thanks. I commented in issue 95675.
Removed the workaround since issue 95675 is now resolved. Checking in unit/PUDataObject.java; /cvs/j2ee/persistence/src/org/netbeans/modules/j2ee/persistence/unit/ PUDataObject.java,v <-- PUDataObject.java new revision: 1.4; previous revision: 1.3 done Checking in unit/PUDataLoader.java; /cvs/j2ee/persistence/src/org/netbeans/modules/j2ee/persistence/unit/ PUDataLoader.java,v <-- PUDataLoader.java new revision: 1.5; previous revision: 1.4 done Checking in provider/ProviderUtil.java; /cvs/j2ee/persistence/src/org/netbeans/modules/j2ee/persistence/provider/ ProviderUtil.java,v <-- ProviderUtil.java new revision: 1.14; previous revision: 1.13 done
Verified