The bad URL in the log is just a log issue. Should be

                                                     vvvv
            Installer.log.severe("JavaHelp manifest: jar:" +
                                 getCodeLocation(jh.getClass()) +
                                 "!/META-INF/MANIFEST.MF"); // NOI18N
                                  ^

(In reply to comment #1)
> The bad URL in the log is just a log issue.

I'm not sure that it is a log issue. 

My original log statement 
http://hg.netbeans.org/main/file/048744607755/javahelp/src/org/netbeans/modules/javahelp/JavaHelp.java#l944
without any predefined protocol prefix and it shows the bad URL too if 
the NetBeans application is started via JNLP. 

The bad URL is obtained via the following expression in the method
getCodeLocation(Class c):

c.getProtectionDomain().getCodeSource().getLocation().toString();

I hope, the expression above is correct.

Please, ignore my comment #2. Draft text has been wrongly committed, sorry. 

The proposed fix in the comment #1 won't work in non-JNLP mode, because the getCodeLocation(Class c) will return a string like this: 
jar:file:/V:/hg.netbeans.org.6.8/main/nbbuild/netbeans/platform11/modules/ext/jh-2.0_05.jar!.

Unfortunately, I've not found a true cause of this issue yet.

I've added some debug info in the code of the JavaHelp and recompiled it. The log of the launching of a NetBeans application with such replacement for the jh-2.0_05.jar is attached.

The log shows the errors "UIDefaults.getUI() failed: no ComponentUI class" for all GUI components of the JavaHelp.
The ComponentUI classes (i.e. like  HelpUI=javax.help.plaf.basic.BasicHelpUI) are accessible via used com.sun.jnlp.JNLPClassLoader. They are installed as the Look And Feel Defaults via the javax.help.SwingHelpUtilities.installUIDefaults() method (see messages with "GUIHelpUtilities:" in the log).
Nevertheless, they are not accessible via the method UIDefaults.getUI() at instantiation of the JavaHelp components if the NetBeans application is launched in the JNLP mode. I don't understand why.

Seems this issue will be fixed if access to the ComponentUI classes will be repaired  in the JNLP mode.

Created attachment 91385 [details]
Log after launching of the NetBeans application with modified ext-jh-2.0_05.jar

In the current implementation in the JNLP mode NB's SystemClassLoader[42 modules] is registered in the javax.swing.UIManager (i.e. AFAIU in the javax.swing.UIDefaults) as the "ClassLoader",
but an actual class loader of the JavaHelp classes is com.sun.jnlp.JNLPClassLoader.

The following lines

           ClassLoader jhClassLoader = JHelp.class.getClassLoader();
           UIManager.put("ClassLoader", jhClassLoader);

before the first instantiating of the JHelp class partly resolve the issue.

At least after such fix I see "normal" JavaHelp window, but the default master help set has been displayed instead of existing help set associated with a NB module that is bundled into the launched NB application.

UIManager.put("ClassLoader", jhClassLoader) is obviously unacceptable as a workaround since that would affect any Swing component loaded in the app.

The various other exceptions in your log file, e.g. CNFE on NbDocsStreamHandler$Factory, are disturbing - but I cannot reproduce them.

NbDocsStreamHandler$Factory no longer exists in current sources. Nor does ExceptionVisualizerProvider. Do a clean build of your source tree to get rid of this old junk.

Something seems to be wrong with class loading of jh.jar in JNLP mode - but only this JAR.

import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
public final class DiagAction implements ActionListener {
    public void actionPerformed(ActionEvent e) {
        diagnose("T.cT.cCL", Thread.currentThread().getContextClassLoader());
        diagnose("CL.sCL", ClassLoader.getSystemClassLoader());
    }
    private void diagnose(String what, ClassLoader l) {
        System.err.println(what + "=" + l);
        diagnose2(l, DiagAction.class.getName());
        diagnose2(l, "javax.help.JHelp");
        diagnose2(l, "org.netbeans.modules.javahelp.JavaHelp");
        diagnose2(l, "org.jdesktop.layout.GroupLayout");
    }
    private void diagnose2(ClassLoader l, String clazz) {
        try {
            Class c = l.loadClass(clazz);
            System.err.println("loaded " + clazz + ": " + c.getProtectionDomain().getCodeSource().getLocation());
        } catch (ClassNotFoundException x) {
            x.printStackTrace();
        }
    }
}

run in normal mode shows all four classes being loaded as expected. In JNLP mode, JHelp cannot be loaded but the other three can:

ClassNotFoundException: javax.help.JHelp starting from SystemClassLoader[42 modules] with possible defining loaders null and declared parents []

Regression due to fix of bug #159586:

  OpenIDE-Module-Hide-Classpath-Packages: javax.help.**, com.sun.java.help.**

causes PCL to refuse to load classes from jh.jar because it thinks these are part of the JRE when in fact they are part of the JNLP app.

Actually exists in 6.7 too. Not hard to fix once diagnosed: core-main #57bff5dfd9ba

Integrated into 'main-golden', will be available in build *200911211401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/57bff5dfd9ba
User: Jesse Glick <jglick@netbeans.org>
Log: #177120: ignore OpenIDE-Module-Hide-Classpath-Packages in JNLP mode.
Always delegate to the JNLPClassLoader since it probably can load the classes from the module.
("Parent" set and "delegate" starting from "system class loader" are always empty in JNLP mode, since PCL is not used for modules.)
If the classes are in fact present in the JRE, then they will be loaded from there, but not much we can do about that;
running in JNLP mode normally disables the various class loading checks of the NB module system.
If you wanted your jh.jar to override any present in the JRE, you would have to configure this in the JNLP descriptor.

Integrated into 'main-golden', will be available in build *200911220201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/ea7f545a103d
User: Jesse Glick <jglick@netbeans.org>
Log: Simplifying log message mentioned in #177120, since it was often incorrect anyway.
(Technically: JarClassLoader produces jar:file:/.../jh.jar!/ URLs as a codebase location, which is correct.
URLClassLoader as created by JRE code produces either file:/.../jh.jar or jar:file:/.../jh.jar.
The first is a valid URL but not a folder, thus not a codebase; and the second is just wrong.
Similarly with http://.../.../jh.jar and so on.)