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.
(sources from 0214) I have a piece of code that creates a persistence.xml file with some initial content (namely with the declaration) inside of a FileSystem.AtomicAction by using the FileUtil.copyFile(..) method. I'm however observing that the DataObject.find(fo) method is called before the created file has any content, which causes the file to be associated with an incorrect DataObject. This behaviour seems to be introduced quite lately, perhaps during this week. The code for creating the file is as follows (you can find it in the j2ee/ persistence module, org.netbeans.modules.j2ee.persistence.provider.ProviderUtil#createPersistenceDDFile(Project)): persistenceLocation.getFileSystem().runAtomicAction(new FileSystem.AtomicAction() { public void run() { try { dd[0] = FileUtil.copyFile(Repository.getDefault().getDefaultFileSystem().findResource( "org-netbeans-modules-j2ee-persistence/ persistence-1.0.xml"), persistenceLocation, "persistence", "xml"); //NOI18N } catch (IOException ex) { ErrorManager.getDefault().notify(ex); } } }); To my understanding using the AtomicAction should guarantee that the association of the data object should happen when the file has been fully constructed, is that correct or is there another way to achieve the desired behaviour?
FileSystem.AtomicAction guarantees just that events created during atomic action are fired after atomic action has finished. There is no guarantee that the association of the data object should happen when the file has been fully constructed. I don't know how to 100% prevent it with current API. No bug in FS.
Have there been any changes in this area lately? This used to work after doing the copying inside of an AtomicAction. Although I can not say when exactly this stopped working, it does work in 5.5. I'm inclined to think that the change related to this is not in our code, since the same behaviour can be observed with other DataObjects as well (for example with the DDDataObject that is associated with web.xml file).
Not aware about changes in FS.
OK, any chance to get this enhancement implemented for 6.0? Although for now I can probably workaround this by creating the file with a different extension and renaming it then.
I don't plan it for 6.0.
As the stack traces in issue 95386 desc7 prove, the contract of FileSystem.runAtomicAction(), which states that in an atomic action no file change events for the respective file system are fired, is broken: the master file system sends some events under its friend contract with the VCS modules. The local history module has the opportunity to recognize the file before it has been fully created (from j2ee/persistence's point of view). Although it might be possible to fix the local history module for now, the hook that the master file system causes the whole AtomicAction concept to be unreliable. Perhaps the could be a way (and it would be sufficient for the VCS modules) to send these events upon exiting the AtomicAction, but before the regular FileChangeEvent's are sent.
I hasitate that issue 95386 desc7 proves broken contract: 1/ FilesystemInterceptor$DelegatingInterceptor.beforeCreate line: 309 is called before FileObject is actually created - so there shouldn't be any problem 2/called when atomic action exited - which is right 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 So, I probably missed something - could you explain? There is method createSucces which is called before atomic action is finished, but this isn't nowhere mentioned in your stacktraces. Moreover Maros claimed that they actually do not use this method - so we could either eliminate createSucces or I can fix it in filesystems - I have test proving it and also fix but I hasitate that its cause of your problem (see the lines above). If you can reproduce the problem you should be also able to trace the problem.
Sorry, I overlooked createSucces in the first stacktrace because beforeCreate attracted my attention. Fixed. But as I said I think that method createSucces is now useless and is not necessary. Maros, Tomas, please comment. /cvs/openide/masterfs/src/org/netbeans/modules/masterfs/MasterFileObject.java,v <-- MasterFileObject.java new revision: 1.63; previous revision: 1.62 /cvs/openide/masterfs/src/org/netbeans/modules/masterfs/Delegate.java,v <-- Delegate.java new revision: 1.25; previous revision: 1.24 test/unit/src/org/netbeans/modules/masterfs/providers/ProvidedExtensionsTest.java; /cvs/openide/masterfs/test/unit/src/org/netbeans/modules/masterfs/providers/ProvidedExtensionsTest.java,v <-- ProvidedExtensionsTest.java new revision: 1.7; previous revision: 1.6
- as much i know the versioning spi (and so the Local History) doesn't depend on createSucces. - regarding issue #95386 - since some time the Local History doesn't go after fileobjects while processing events from the FS
OK, but do you need then createSuccess anymore? Can we delete it from our frined contract if this method more or less duplicates fileDataCreated?
We use beforeCreate(FileObject parent, String name, boolean isFolder); createSuccess() and createFailure() are not used now and can be deleted IMHO if it solves the issue.