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.
[3.2] Lookup with a custom DTD instance does not seem to be 100% reliable. For example, apisupport's support for custom cookie lists does not always work. It defines a DTD (and registers a local copy via layer and an XMLDataObject.Processor via ModuleInstall) and also creates a service via that DTD in Services/Hidden/. Sometimes it works. Then, sometimes it does not: Processor.attach is not called even though Lookup.lookup(Template) was called; then later Processor.attach *is* called, but not InstanceCookie.instanceCreate. If you fool around with the file (make a copy of it in the SFS, etc.) then this triggers a refresh and everything works. You can see whether it is working by looking at Runtime | Bean Browser | Project Default | Cookies..., which should show a bunch of subnodes if all is well. Observed also in trunk; find some data object in some filesystem under TopManager | Repository, then its nodeDelegate should have itself as a cookie.
Target milestone -> 3.3
Still broken in [dev may 23].
I am working around this bug in the dev version of apisupport, until it is fixed.
org.openide.util.lookup.ProxyLookup has been improved in rev. 1.2, so this should be fixed. At least test core/test/unit/src/.../lookup/LookupTest seems to be ok.
Workaround removed in apisupport, and it works without it.
Reopening. Original situation still works but similar one does not: after reinstalling a module its Services/Hidden/*.instance was recognized and a new instance created, but lookup did not see this new instance until later (after adding a dummy *.url to the Services/Hidden/ folder) at which point it was fine. [dev aug 13]
Right now I have fixed FolderInstance.testModificationOnSubfolder test. Which in my opinion simulates exactly what you have described - conntent of folder/subfolder is modified and the FolderInstance on folder is asked for result. Now it works. Thus I think that also the FolderLookup will work that way.
Still broken [dev aug 23]. To observe: run IDE with modules including ant and apisupport (i.e: -Dmodules=ant,apisupport,apisupport/lite,jarpackager,openidex,utilities). -J-Dorg.apache.tools.ant.module=0 -J-Dorg.netbeans.core.modules=0 is best. Run ant/build.xml:test target to reinstall Ant module; this succeeds since <nbinstaller> is defined. Now run it again; it may succeed again, not clear. Run apisupport/build.xml:test-everything target, it fails: "Could not create task with name nbinstaller...". This means that the new version of the Ant module does not see the taskdef (registered by apisupport+ant) in Lookup. Make the SFS visible, browse to the Services/Hidden/ folder, you will see the apisupport taskdef .instance there; Bean Browse indicates it does have InstanceCookie with the correct taskdef. However ide.log says that "All DefinitionRegistry's in lookup: []", i.e. it got no results. Create a dummy file (e.g. a new URL) in Services/Hidden/. Suddenly the log file says that there _is_ a DR in Lookup, and will also say "Registering new def from lookup: name=nbinstaller". At this point it is possible to run apisupport/build.xml:test-everything successfully (reloading all three apisupport modules). The trick generally does not work more than once however.
I have investigated this issue and it is pretty complicated. The easiest fix should be in InstanceDataObject to revalidate itself when its module is uninstalled/installed again (for both .settings/.instance files). Because it seems that when a module is disabled/reenabled the InstanceDataObject remains the same(!!!) and has the same InstanceCookie, but obviously returning different class after the reload. Jesse what do you do when you reinstall a module? How can AntExecutor (SL[/Executor/AntExecutor) data object remain the same?
AntExecutor? I am not sure what you mean, I was not aware of any problem with AntExecutor. The module does not do anything strange (that I know of) when reloading; the stuff is defined in layers. For the <nbinstaller> stuff, the instance is coming from apisupport+ant module, which has a .instance file with a custom methodvalue createInstance (which calls into the ant module with some parameters). Since when Ant is reloaded, apisupport+ant is too, I would expect an entirely different InstanceDataObject to be created (or at least its cookie to change). Is this a bad assumption?
Currently <nbinstaller> is recognized sometimes after a reload of Ant, but not always, so it seems to have to do with timing. I think if you manually turn off ant and apisupport+ant, then manually turn them back on, it is OK; but using an automated reload it is not. This makes it sound like the InstanceDataObject as you say is not getting changed, perhaps because no file event is fired across the reload, or the effects are cancelled. If I knew what exactly filesystems + datasystems need in order to convince them to refresh the IDO, the module system could do this during a reload (which is normally run inside a module system mutex, and the disabling and enabling each run within a filesystem atomic block as far as layers go).
InstanceDataObject stops all optimization of instaceOf method when a module is disabled (property "classLoader") is fired.
Resolved for 3.4.x or earlier, no new info since then -> verified.
Resolved for 3.4.x or earlier, no new info since then -> closing.