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.
I got following exception during creating new visual midlet in the new netbeans userdir: java.lang.IllegalStateException: The data object MasterFileObject@15f9d52[E:/Projects/Crap/MobileApplication1/src/ma1/VisualMIDlet.java] is invalid; you may not call getNodeDelegate on it any more; see #17020 and please fix your code at org.openide.loaders.DataObject.getNodeDelegate(DataObject.java:245) at org.netbeans.modules.mobility.editor.pub.J2MEDataObject$J2MEEditor.initialize(J2MEDataObject.java:354) at org.netbeans.modules.mobility.editor.pub.J2MEDataObject$J2MEEditor.<init>(J2MEDataObject.java:333) at org.netbeans.modules.mobility.editor.pub.J2MEDataObject$J2MEEditorSupport.createCloneableEditor(J2MEDataObject.java:315) at org.openide.text.CloneableEditorSupport.createPane(CloneableEditorSupport.java:983) at org.openide.text.CloneableEditorSupport.createCloneableTopComponent(CloneableEditorSupport.java:976) at org.openide.windows.CloneableOpenSupport.openCloneableTopComponent(CloneableOpenSupport.java:175) at org.openide.windows.CloneableOpenSupport$1.run(CloneableOpenSupport.java:76) at org.openide.util.Mutex.doEvent(Mutex.java:1181) at org.openide.util.Mutex.writeAccess(Mutex.java:376) at org.openide.windows.CloneableOpenSupport.open(CloneableOpenSupport.java:73) at org.openide.text.CloneableEditorSupport.open(CloneableEditorSupport.java:392) at org.openide.actions.OpenAction.performAction(OpenAction.java:59) at org.openide.util.actions.NodeAction$DelegateAction$1.run(NodeAction.java:559) at org.netbeans.modules.openide.util.ActionsBridge.doPerformAction(ActionsBridge.java:55) at org.openide.util.actions.NodeAction$DelegateAction.actionPerformed(NodeAction.java:555) at org.netbeans.modules.project.ui.ProjectUtilities$3.run(ProjectUtilities.java:257) at org.openide.util.Mutex.doEvent(Mutex.java:1181) at org.openide.util.Mutex.writeAccess(Mutex.java:376) at org.netbeans.modules.project.ui.ProjectUtilities.openAndSelectNewObject(ProjectUtilities.java:249) at org.netbeans.modules.project.ui.actions.NewFile.doPerform(NewFile.java:150) at org.netbeans.modules.project.ui.actions.NewFile.access$200(NewFile.java:58) at org.netbeans.modules.project.ui.actions.NewFile$PopupListener.actionPerformed(NewFile.java:319) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242) at javax.swing.AbstractButton.doClick(AbstractButton.java:357) at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1170) at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1211) at java.awt.Component.processMouseEvent(Component.java:6038) at javax.swing.JComponent.processMouseEvent(JComponent.java:3260) at java.awt.Component.processEvent(Component.java:5803) at java.awt.Container.processEvent(Container.java:2058) at java.awt.Component.dispatchEventImpl(Component.java:4410) at java.awt.Container.dispatchEventImpl(Container.java:2116) at java.awt.Component.dispatchEvent(Component.java:4240) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916) at java.awt.Container.dispatchEventImpl(Container.java:2102) at java.awt.Window.dispatchEventImpl(Window.java:2429) at java.awt.Component.dispatchEvent(Component.java:4240) [catch] at java.awt.EventQueue.dispatchEvent(EventQueue.java:599) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160) at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
Created attachment 37390 [details] stacktrace
please, do not paste long stacktraces to comments. Add them as attachments. It's easier to search for duplicates later.
I do not know how to improve the new-file creation. It is still the same problem with data-object invalidation. Adame, do you how to solve this for asure 100% fix. It looks like the data-object invalidation is done asynchronously since the re-validation is always done after the new-file creation.
Created attachment 37394 [details] another log
Another exception (see attachment above): close IDE, remove visualMidlet.java, visualMidlet.form in th filesystem. Start IDE, try to create new visual midlet.
The second exception is related to a general problem in FileSystems module. External file deletion is not automatically propagated to the FileSystem layer. Since the layer caches file descriptors then it still thinks that the file still exists. Maybe invoking "File | Refresh All Files" main menu action would help you.
still happens in 0119 build when creating new visual midlet
definitely stopper for M7, really annoying issue that confuses users when they creates a new file
seems that the issue disappeared. I'll remove it from stoppers list tomorrow if it won't appear.
It was fixed a few weeks ago.
ok, then verifying. I haven't seen it for long time
trunk Feb/20/2007 - the exception is still there though the stacktrace looks different. Reopening.
Created attachment 38728 [details] stacktrace
removing it from M7 stoppers list. Doesn't happen in M7 (at least it haven't happened to me or Fabi). Seems that's neverending story. There are 4 weeks till next milestone. Please fix it with cooperation with other teams.
Created attachment 38806 [details] another exception with latest(0222) David's hack
A partial workaround has been added. It is forcing the refresh of fileobjects in parent folder right after a new file is created. This should enforce data-object revalidation.
Created attachment 38808 [details] DataObject invalidation within the DataObject.createFromTemplate method call
Created attachment 38809 [details] DataObject invalidation within asynchronous FolderList.Task.run method call
Jardo, could you please look at invalidate-within-createFromTemplate.txt and invalidate-asynchronously-within-folder-list.txt stack traces? Thanks. The first is happening most of the time, and therefore the DataObject returned by DataObject.createFromTemplate method is returned as invalid. The second stack invalidation is happening rarely and is not covered by our workaround. Here is the workaround: // reqular code DataObject fromTemplate = tpl.createFromTemplate (target, name); // this reduces amount of "uncovered" cases to +- 1% fromTemplate.getPrimaryFile ().getParent ().refresh (true); // this a simple workaround for invalidation // within the "DataObject.createFromTeamplate" method call: fromTemplate = DataObject.find (fromTemplate.getPrimaryFile ());
Adding dependency on issue #95399. After switching to FreeMaker, the file creation should not use refactoring at all and therefore the data-object should not be invalidated. After fixing the issue issue #95399, the workaround above is going to be removed.
Observed the same issue : Build : 20070311 with JDK 1.6 on XP. Creating CDC application. After adding CDC platform Exception poped in the IDE.
This bug is caused by issue #95399. Setting Target milestone to 6.0.
Adame, the FreeMaker was integrated. Could you change the new-file creation to the new API. For more info see: http://www.netbeans.org/download/dev/javadoc/org-openide-loaders/apichanges.html#scripting The Designer1 and Designer2 are going to use ${name} and ${user} attributes and license section. Thanks.
Adding dependency on issue #100763 which describes endless-loop while FreeMarker engine is used.
Fixed in main trunk.
Created attachment 41480 [details] stacktrace from 0423 build
reopening - happend when creating new Visual Midlet in 0423 build. I used the NBI standard installer
Issue #102629 is the root cause of this issue.
The issue #102629 has been fixed in main trunk. Therefore removing the workaround (in FileWizardIterator) from main trunk. Still leaving the issue open, since the issue #102629 is not fixed in Milestone 9.
changing the Target Milestone to TBD because the origin one finished already. Please reschedule
Setting a TM to 6.0M9 since the issue #102629 was fixed on the second in Milestone 9. The fix makes this issue to be fixed.
this issue is back. Roumen, had to skipped the Mobility demo with M9 because of the exception. I'm not sure that is the same behavior. It happened to him when created CDC project. Roumen, do you have the stacktrace? Please, assign it here and reopen or fill a new issue when it's different to those already attached. thanks
roumene, what build exactly are you using?
Version: NetBeans IDE 6.0 Preview (M9, build 070501) I do not have the full stacktrace (for some reason it is not in messages.log) but this is what I found in uigestures: <message>java.lang.IllegalStateException: The data object MasterFileObject@ab2113[C:/demo/CdcApplication7/src/cdcapplication7/Main.java] is invalid; you may not call getNodeDelegate on it any more; see #17020 and please fix your code</message>
This new IllegalAccessException is not completely a new issue. It is caused by file templates in CLDC and CDC project modules which are not converted to use Template-Scripting feature.
Sorry for typo: The new appearance of the issue is not related to Visual Designer. It is caused in CLDC and CDC project modules.
if this is caused by old templates style then it is already fixed in M10
verified in beta1 09/11 build