NoClassDefFoundError error on a Netbeans application using OSGi

[YannLeCorse]

Hi,

I'm facing exceptions at the startup of a Netbeans application based on Maven and using OSGi.
This is a sample project to reproduce the issue I'm facing : my-application.zip

• I created a nbm-application with OSGi enabled
• I created an OSGi module defining interface A
• I created a NBM module containing
  • Interface B extends A
  • Singleton class holding an instance of A
  • ModuleInstall where we inject an instance of B to the singleton above

The project is failing in the application unit test do to the issue but it's easier to run it in debug to troubleshot.

At startup, manifests are read and it looks like the OSGi export packages are correctly initialised in the org.netbeans.ModuleData as I can see them in provides

Then we go through the org.netbeans.ModuleManager.doEnable() and it looks like we don't have the same process for OSGi modules and for Netbeans ones.

Netbeans modules are looking for their public packages and register them in the ProxyClassPackages

"main"
        at org.netbeans.ProxyClassPackages.addCoveredPackages(ProxyClassPackages.java:45)
	at org.netbeans.ProxyClassLoader.addCoveredPackages(ProxyClassLoader.java:94)
	at org.netbeans.JarClassLoader.<init>(JarClassLoader.java:177)
	at org.netbeans.StandardModule$OneModuleClassLoader.<init>(StandardModule.java:609)
	at org.netbeans.StandardModule.createNewClassLoader(StandardModule.java:545)
	at org.netbeans.StandardModule.classLoaderUp(StandardModule.java:533)
	at org.netbeans.ModuleManager.doEnable(ModuleManager.java:1380)
	at org.netbeans.ModuleManager.enable(ModuleManager.java:1350)
	at org.netbeans.ModuleManager.enable(ModuleManager.java:1275)
	at org.netbeans.core.startup.ModuleList.installNew(ModuleList.java:316)
	at org.netbeans.core.startup.ModuleList.trigger(ModuleList.java:252)
	at org.netbeans.core.startup.ModuleSystem.restore(ModuleSystem.java:298)
	at org.netbeans.core.startup.Main.getModuleSystem(Main.java:173)
	at org.netbeans.core.startup.Main.getModuleSystem(Main.java:142)
	at org.netbeans.core.startup.Main.start(Main.java:303)
	at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:98)
	at java.lang.Thread.runWith(Thread.java:1596)
	at java.lang.Thread.run(Thread.java:1583)

OSGi modules are doing something quite similar but don't register their export packages in the ProxyClassPackages

"main"
	at org.netbeans.NetigsoHandle.classLoaderUp(NetigsoHandle.java:163)
	at org.netbeans.ModuleManager.netigsoLoaderUp(ModuleManager.java:601)
	at org.netbeans.NetigsoModule.classLoaderUp(NetigsoModule.java:108)
	at org.netbeans.ModuleManager.doEnable(ModuleManager.java:1380)
	at org.netbeans.ModuleManager.enable(ModuleManager.java:1350)
	at org.netbeans.ModuleManager.enable(ModuleManager.java:1275)
	at org.netbeans.core.startup.ModuleList.installNew(ModuleList.java:316)
	at org.netbeans.core.startup.ModuleList.trigger(ModuleList.java:252)
	at org.netbeans.core.startup.ModuleSystem.restore(ModuleSystem.java:298)
	at org.netbeans.core.startup.Main.getModuleSystem(Main.java:173)
	at org.netbeans.core.startup.Main.getModuleSystem(Main.java:142)
	at org.netbeans.core.startup.Main.start(Main.java:303)
	at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:98)
	at java.lang.Thread.runWith(Thread.java:1596)
	at java.lang.Thread.run(Thread.java:1583)

As a result, when my NBM module is starting, it tries to load the class A defined in my OSGi module.
As export packages were not registered, we don't find them in the ProxyClassPackages and the exception is thrown.

From my understanding it looks like there is an issue in the way we are managing OSGi modules but I'm opening this discussion to validate that I got it right.

• Is my understanding correct ?
• Is there any reason why we don't register the export-packages from OSGi modules when we are processing them ?

Thanks

[YannLeCorse]

@ebarboni, @mbien sorry for tagging you (I don't know who else to annoy 😝) but I'd like to know if it's sound like a bug (and then I'm happy to work on it) or if it's a bad practice on my side. Would you have a quick look and share your thoughts please ?

[mbien]

sorry for tagging you (I don't know who else to annoy 😝)

unfortunately (or luckily?), I never went deep into OSGI. But I do know who else to annoy. cc @jtulach @matthiasblaesing @neilcsmith-net

[YannLeCorse]

Hi guys,

From my understandng the issue I'm facing is related to the delayed OSGi modules start.
Thus when we are trying to find the validate method, classpaths haven't been initialised properly and we're facing the NoClassDefFoundError.

The scenario seems to be limited to NB modules having a ModuleInstall "linked" to classes from an OSGi module.
Is there a way to disable the delayed OSGi module start ?
If not, would it makes sense to ignore the NoClassDefFoundError at this stage and let the process continue ? (a bit like what is curently done for modules not implementing the validate method)
Going that way, the modules will start as expected but if the validate method was implemented, it'd not be called.

What's your views ?

Thx
Yann

[matthiasblaesing]

Please provide a minimal sample. Guessing does not help.

[YannLeCorse]

Please provide a minimal sample. Guessing does not help.

There is one attached in the initial message

[neilcsmith-net]

From what I can see, changing the ModuleInstall in the example from

public class Installer extends ModuleInstall {

    @Override
    public void restored() {
        MyService.getInstance().setRegistry(new INbRegistry() {
            @Override
            public void doSomethingElse() {
            }

            @Override
            public void doSomething() {
            }
        });
    }

}

to

public class Installer extends ModuleInstall {

    @Override
    public void restored() {
        Handler.restored();
    }

    private static class Handler {

        private static void restored() {
            MyService.getInstance().setRegistry(new INbRegistry() {
                @Override
                public void doSomethingElse() {
                }

                @Override
                public void doSomething() {
                }
            });
        }

    }

}

is enough to not fail on load. Adding a validate method also shows that is correctly handled.

[neilcsmith-net]

I missed your reply while writing that! The important problem with the PR is that it will could cause validation to be silently missed?!

[neilcsmith-net]

Incidentally, it's hard to tell from your example why you're using ModuleInstall at all. I would note in the docs for ModuleInstall "most modules should not need this". I assume there is some reason the code in your module install cannot run when loading the services the module provides?

[YannLeCorse]

I'm moving an old app with 400+ modules from the old wrapper approach to the OSGi ones. ModuleInstaller were used long time ago (before annotations) as we did checks (license, jdk, etc) in validate for few modules + some registration in the restore for main of them.

With wrappers, the various ModuleInstall were called in the module dependencies order and classes are registered sequentially so everything was OK. Unfortunately it's not the case with OSGi 😆.
Annotated classes could be used in some places but as they are processed in parallel it doesn't cover all my needs (at least at start) as ordering is important in my scenario.

I'll close the PR and adapt my own code to the current limitation as suggested as I don't have so many situation where the ModuleInstall is having a dependency to OSGi classes but that needs to be documented as it's error prone and not obvious (especially when not implementing the validate 😄)

Thanks again for your time looking at this 😉

[neilcsmith-net]

It wasn't meant as a comment on ModuleInstall vs the similar annotations. Registering things in a module install seems backwards to the usual way of discovering services through system lookup, layer files, etc. Still, legacy ... 😄

[YannLeCorse]

It sounds like a NB issue rather than a bad design so I created the pull request #7624