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.

Bug 192496 - Lookups.forPath(path).lookupAll(clazz) returns empty collection
Summary: Lookups.forPath(path).lookupAll(clazz) returns empty collection
Alias: None
Product: platform
Classification: Unclassified
Component: Lookup (show other bugs)
Version: 7.0
Hardware: PC Windows XP
: P3 normal (vote)
Assignee: Jaroslav Tulach
Depends on:
Blocks: 179047
  Show dependency tree
Reported: 2010-11-25 23:08 UTC by err
Modified: 2011-02-25 05:35 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

FAIL log (161.07 KB, text/plain)
2011-02-19 19:47 UTC, err
OK log (167.32 KB, text/plain)
2011-02-19 19:48 UTC, err
FAIL case with additional RecognizeInstanceObjects logging (169.00 KB, text/plain)
2011-02-20 23:06 UTC, err

Note You need to log in before you can comment on or make changes to this bug.
Description err 2010-11-25 23:08:15 UTC
This is during startup, in partticular
    for (ViInitialization i : Lookups.forPath("jVi/init")
typically get a 13 item collection; around 40% of the time it's empty.

(I'm almost certain this issue has started with NB7)
(The jvi startup code could use some rework, but...)

  at com.raelity.jvi.manager.ViManager.setViFactory(
  at org.netbeans.modules.jvi.Module$
  at java.awt.event.InvocationEvent.dispatch(
  at java.awt.EventQueue.dispatchEvent(
  at java.awt.EventDispatchThread.pumpOneEventForFilters(
  at java.awt.EventDispatchThread.pumpEventsForFilter(
  at java.awt.EventDispatchThread.pumpEventsForHierarchy(
  at java.awt.EventDispatchThread.pumpEvents(
  at java.awt.EventDispatchThread.pumpEvents(
Caused: java.lang.reflect.InvocationTargetException
  at java.awt.EventQueue.invokeAndWait(
[catch] at org.netbeans.modules.jvi.Module.runInDispatch(
  at org.netbeans.modules.jvi.Module.earlyInit(
  at org.netbeans.modules.jvi.Module.restored(
  at org.netbeans.core.startup.NbInstaller.loadCode(
  at org.netbeans.core.startup.NbInstaller.load(
  at org.netbeans.ModuleManager.enable(
  at org.netbeans.core.startup.ModuleList.installNew(
  at org.netbeans.core.startup.ModuleList.trigger(
  at org.netbeans.core.startup.ModuleSystem.restore(
  at org.netbeans.core.startup.Main.getModuleSystem(
  at org.netbeans.core.startup.Main.start(
INFO [org.netbeans.core.startup.NbEvents]: Turning on modules:
  org.openide.util.lookup [8.5 201011152355]
  org.openide.util [8.9 201011152355]
  org.openide.modules [7.21 201011152355]
Comment 1 err 2010-11-26 04:31:36 UTC
I think this fails only the first time I manually run the platform after installing a new version of jVi. I say manually, because the auto-restart finish button after new install does not fail. This is win-xp.
Comment 2 Jaroslav Tulach 2010-11-26 08:37:12 UTC
Unit test, sample module or instructions to reproduce are necessary.
Comment 3 err 2010-11-27 20:04:29 UTC
(so I guess "Oh, of course" didn't flash through your mind ;-) )

- fails with 7.0M2 and 7.0Beta
- after failure during startup, exit IDE, restart IDE and things are OK.
- Problem code is invoked from via call chain from
  Module.restored. Module.restored thread waits for runnable to complete.
  Failing code in runnable's call chain to ViManager.setViFactory
        for (ViInitialization i
             : Lookups.forPath("jVi/init").lookupAll(ViInitialization.class))
- Tried both EventQueue.invokeAndWait, and invokeLater/CountDownLatch.
- The "AssertionError" essentially means the Lookups.forPath was empty.

Seems to be a timing/threading problem. If you wish to pursue this and considering the difficulty of reproducing failure, with advice I can instrument some check and/or debug output locally.

=== Typical failure steps
Starts with jVi modules installed, jVi modules opened. Editing stuff.
1)  Build a new version of jVi modules, do not change any NB version numbers
un-install jVi
2)  "Tools > Plugins > Installed"; check jViKeyBindings;
    select Uninstall; in IDE installer dialog, select Uninstall
    click finish to restart IDE
install the just created NBMs
3)  "Tools > Plugins > Downloaded" (note that the prior modules listed)
    select Remove twice to clear list of previous
    select AddPlugins...
    navigate to .../dir-with-nbm
    select all modules, select Open,
    select Install (Plugin dialog)
    proceed through install, select Finish
    IDE restarts
4)  exit IDE, start IDE
Observe failure somtimes. Exit/start succeeds.

=== Other observed failure, no new module installations
1) exit IDE
2) build a local copy of IDE, was cleaned before hg fetch yesterday.
3) start IDE
Comment 4 err 2010-11-28 16:58:00 UTC
Another failure observed
1) exit IDE
2) Let system sit overnight, do system-wide backup
3) start IDE
get the failure (note, nothing changed in IDE installation)
4) re-start IDE
and it starts up without the failure.
Comment 5 Jaroslav Tulach 2011-01-08 18:07:41 UTC
Unsufficient info: I don't even know where to get jVi modules. Not even I know how to compile and run them.

You can try to generate more info with:

replace with dotted path to folder your are interested in.
Comment 6 err 2011-01-22 17:07:06 UTC
To get logging info for: Lookups.forPath("jVi/init")
I tried
Never saw anything in messages.log (other than the -Dxxx lines). 

If you want to take a look, following are sibling directories. Open nbvi/nbvi-suite (backwards for historical reasons...) and create NBMs

Install NBMs and boot IDE. The error occurs during startup intermittently as described in comments. I use "--console new".

Most recent attempt with:
    Product Version: NetBeans IDE Dev (Build 201101200001)
    Java: 1.6.0_23; Java HotSpot(TM) Client VM 19.0-b09
    System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)
    Userdir: C:\Documents and Settings\erra\.netbeans\dev
Comment 7 err 2011-01-22 18:22:00 UTC
I think there's a misunderstanding about the lookup I'm doing. I put a println in
    private FolderInstance (DataObject.Container container, String logName) {
and never found a logName that looked relevant.

The stuff being looked up comes from things like:
    public static class Init implements ViInitialization
Comment 8 Jaroslav Tulach 2011-01-24 14:35:29 UTC
(In reply to comment #6)
> To get logging info for: Lookups.forPath("jVi/init")
> I tried
> -Dorg.openide.loaders.FolderInstance.META-INF.namedservices.jVi.init.level=FINE
>     -Dorg.openide.loaders.FolderInstance.namedservices.jVi.init.level=FINE
>     -Dorg.openide.loaders.FolderInstance.jVi.init.level=FINE
> Never saw anything in messages.log (other than the -Dxxx lines). 

The above is no way logging for jVi/init. That would be

Please show me typical code that does the registration.
Comment 9 err 2011-01-24 17:02:28 UTC
(In reply to comment #8)

> Please show me typical code that does the registration.

Comment 7 has example of registration

> That would be
> -Dorg.openide.loaders.FolderInstance.Services.jVi.init.level=FINE
Ok, thanks.

    Input arguments:

Still no output. But as mentioned in comment 7 there is no logName in any FolderInstance that has the word jVi in it. A different class must be used for this situation (for "Services"?).
Comment 10 Jaroslav Tulach 2011-02-18 17:55:50 UTC
Running with
generates tons of output for me. I don't know what is wrong in your case.
Comment 11 err 2011-02-18 20:20:39 UTC
(In reply to comment #10)
> Running with
> -J-Dorg.openide.loaders.FolderInstance.Services.JavaHelp.level=FINEST
> generates tons of output for me. I don't know what is wrong in your case.

This bug is about an intermittent failure of Lookups.forPath(path) (after a failure simply exit and restart IDE and it works). If you'd like, I can file a separate bug about the logging failure. Could logging be failing because registered with annotations or maybe because path is two components?

About this bug; comment 4 is typical failure, looks like a timing problem; comment 7 shows the annotation used; comment 6 shows how the source for the modules can be retrieved.

Beta2 has same problems.
Comment 12 err 2011-02-19 00:51:21 UTC
Some of the confusion may be that the annotation being used
puts stuff into
not into ".../Services/..."
Comment 13 Jaroslav Tulach 2011-02-19 10:52:03 UTC
In such case the proper logging would be

As far as I can tell, your code asks for getResources(
and founds nothing. In what JAR you should have these resources? It is not in jvi-debug.jar (in spite it is in classes directory):

jvi/build$ unzip -v lib/jvi-debug.jar | grep ViInit
jvi/build$ find classes/ | grep ViInit
Comment 14 Jaroslav Tulach 2011-02-19 10:54:25 UTC
The problem is in your build.xml:
>           includes="com/raelity/**"
Comment 15 err 2011-02-19 19:07:19 UTC
(In reply to comment #13)

> As far as I can tell, your code asks for getResources(
> "META-INF/namedservices/jVi/init/com.raelity.jvi.ViInitialization"
> )
> and founds nothing. In what JAR you should have these resources? It is not in
> jvi-debug.jar (in spite it is in classes directory):
(the standalone jvi-debug.jar has not been tested/used since the change to @ServiceProvider, thanks for the heads up)

The module suite is at .../nbvi/nbvi-suite (see comment 6.)

/modules/ $ pwd
/modules/ $ jar -tf ext/jvi-project.jar |grep ViInit
/modules/ $ jar -tf org-netbeans-modules-jvi.jar |grep ViInit
Comment 16 err 2011-02-19 19:46:31 UTC
(In reply to comment #13)
> In such case the proper logging would be
> -Dorg.openide.util.lookup.MetaInfServicesLookup.level=FINEST

Attaching a OK and FAIL messages.log. The trace shows that in the FAIL case the BootClassLoader is used to create the MetaInfServicesLookup.  I'm guessing that's the key.

    FINE [org.openide.util.lookup.MetaInfServicesLookup]:
        Created: MetaInfServicesLookup[SystemClassLoader[374 modules]]
    FINER [org.openide.util.lookup.MetaInfServicesLookup]:
        Searching for com.raelity.jvi.ViInitialization
        in ModuleCL@9e8c34 [com.raelity.jvi]
        from MetaInfServicesLookup[SystemClassLoader[374 modules]]

    FINE [org.openide.util.lookup.MetaInfServicesLookup]:
        Created: MetaInfServicesLookup
    FINER [org.openide.util.lookup.MetaInfServicesLookup]:
        Searching for com.raelity.jvi.ViInitialization
        in ModuleCL@8de972[com.raelity.jvi]
        from MetaInfServicesLookup
Comment 17 err 2011-02-19 19:47:51 UTC
Created attachment 106194 [details]
FAIL log
Comment 18 err 2011-02-19 19:48:19 UTC
Created attachment 106195 [details]
OK log
Comment 19 Jaroslav Tulach 2011-02-19 22:12:13 UTC
As soon as ergonomics#dbd35f898983 is in, use:
and generate me the failure case log. Thanks.
Comment 20 err 2011-02-20 23:06:34 UTC
Created attachment 106222 [details]
FAIL case with additional RecognizeInstanceObjects logging

Starting at line 178 of log:

FINEST [org.netbeans.modules.settings.RecognizeInstanceObjects]:
    allCL: [SystemClassLoader[376 modules]]
FINEST [org.netbeans.modules.settings.RecognizeInstanceObjects]:
    ccl: org.netbeans.MainImpl$BootClassLoader@c53dce
FINER [org.netbeans.modules.settings.RecognizeInstanceObjects]:
    metaInfServices for [org.netbeans.MainImpl$BootClassLoader@c53dce]
FINE [org.openide.util.lookup.MetaInfServicesLookup]:
    Created: MetaInfServicesLookup[org.netbeans.MainImpl$BootClassLoader@c53dce]
FINER [org.openide.util.lookup.MetaInfServicesLookup]:
    Searching for com.raelity.jvi.ViInitialization
    in ModuleCL@200db9[com.raelity.jvi]
    from MetaInfServicesLookup[org.netbeans.MainImpl$BootClassLoader@c53dce]
FINER [org.openide.util.lookup.MetaInfServicesLookup]:
    Found impls of com.raelity.jvi.ViInitialization: [] and removed: []
    from: MetaInfServicesLookup[org.netbeans.MainImpl$BootClassLoader@c53dce]
Comment 21 Jaroslav Tulach 2011-02-21 13:19:19 UTC
Comment 22 Quality Engineering 2011-02-25 05:35:09 UTC
Integrated into 'main-golden', will be available in build *201102250001* on (upload may still be in progress)
User: Jaroslav Tulach <>
Log: #192496: Prefer ClassLoader from Lookup over Thread.currentClassLoader