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 76196 - JNLP generation should behave better out of the box for native libraries
Summary: JNLP generation should behave better out of the box for native libraries
Status: NEW
Alias: None
Product: apisupport
Classification: Unclassified
Component: Harness (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker with 2 votes (vote)
Assignee: pgebauer
: 192648 (view as bug list)
Depends on:
Reported: 2006-05-11 09:54 UTC by timdudgeon
Modified: 2015-09-09 11:22 UTC (History)
3 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description timdudgeon 2006-05-11 09:54:41 UTC
Building a Java Web Start version of a platform based app fails if a module
includes native libraries.
For instance, if the External Browser module is included the build fails as the
.dll or .so files are not referenced from the jnlp file.

/home/tim/netbeans/netbeans-5.0/harness/suite.xml:188: The following
error occurred while executing this line:
/home/tim/netbeans/netbeans-5.0/harness/jnlp.xml:116: Cannot build JNLP
for module
as these files are in module's NBM, but are not referenced from any path:
[modules/lib/extbrowser.dll, modules/lib/extbrowser64.dll] 

Some mechanism is needed for incorporating the native libraries into the jnlp
descriptor so that they can be used. Something like this:

<nativelib href="lib/windows/corelib.jar"/>

<resources os="SunOS" arch="sparc">
    <nativelib href="lib/solaris/corelibs.jar"/>
Comment 1 Jesse Glick 2006-05-12 02:31:57 UTC
I think you need to build the .jnlp for this module manually at the moment.
Unfortunately AFAIK that is impossible for external modules (it is possible for modules). Yarda can comment.
Comment 2 Jaroslav Tulach 2006-05-12 16:01:13 UTC
Imho it works. 

ant -f suite/build.xml build-jnlp

calls on each of its modules

ant -f suite/moduleX/build.xml jnlp

and thus it is possible to overwrite that target to do "what is needed". Right 
now I have to admit I do not know "what is needed", so I leave this open as a 
request for documentation.
Comment 3 timdudgeon 2006-05-12 16:21:52 UTC
The issue (if I understand it correectly) is that the build does not currently
allow a module to define that it needs native libraries that need incorporating
into the Jave Web Start enabled verion of the application.
If a module, such as the External Browser module needs native libraries, then in
order for this module to run as a Java Web Start module then these native
libraries (*.dll, *.so) need to be packaged up inside a jar file, and the .jnlp
file that is generated has to contain elements appropriate for using those
native libraries. e.g 
<nativelib href="lib/windows/corelib.jar"/>

I don't beleive this functionality exists, or it it does is certainly isn't
implemented in the External Browser module.

Is that a bit clearer now?

Comment 4 Lukas Hasik 2008-04-10 21:27:01 UTC
moving opened issues from TM <= 6.1 to TM=Dev
Comment 5 supercode 2008-10-15 00:37:39 UTC
Will this be available in 6.5.
I have an application in which I have generated NB Module wrappers (products like JExcel, CorpsCon, and JOGL) in which 
all of these products are using binary DLL's. The wrapping works fine. And I have success loading many netbean modules I 
have created that contain DLL's (like JExcel)

Even though we can make a very think rich client application by selecting the "Netbean's Platform Application" , it 
unfortunately does not allow for any update centers to be included. So when I do go to turn on the update center capability, it 
however than has a dependency on the NB module using an external browser. Can you guys think of a simpler way to just 
use http socket connections without the need for the browser? I understand that the update center dialogs like to have a link  
referencing the update site, but do we really need to be calling low level browser DLL's. At least this this would fisrt allow me 
to deploy an application and then follow up with with whatever modules I need to download that contain embedded DLL's into 
the application. That way the webstart initially stays very lightweight...

Comment 6 Jesse Glick 2008-10-15 04:11:57 UTC
To use the extbrowser module in JNLP mode you *must* refer to a special JNLP build of the platform. See issue #70477 for
Comment 7 Jesse Glick 2011-04-13 17:06:25 UTC
*** Bug 192648 has been marked as a duplicate of this bug. ***
Comment 8 Jesse Glick 2012-05-02 17:53:32 UTC
For native libraries included with your own suite's modules, you must currently override the jnlp target in your build.xml. extbrowser's script [1] gives the idea.

For native libraries included in the platform, you must define jnlp.platform.codebase or it cannot work.

Leaving open since you might expect that <makejnlp> would "do the right thing" when encountering native library entries:

1. Pack modules/lib/lib*.jnilib into a <nativelib> inside <resources> with os="Mac OS X" (?).
2. Pack modules/lib/ARCH/*.dll with os="Windows" and arch="ARCH".
3. Pack modules/lib/ARCH/SYS/*X* with os="SYS" and arch="ARCH".

Comment 9 Jesse Glick 2012-05-02 18:16:47 UTC
(In reply to comment #8)
> 3. Pack modules/lib/ARCH/SYS/*X* with os="SYS" and arch="ARCH".

Complicated by the fact that SYS must be upcased (e.g. "Linux" not "linux"); cf. core-main #2ed9bef1c084.
Comment 10 Jesse Glick 2012-05-02 19:01:52 UTC
According to spec, os and arch restrictions

1. Match case-sensitively. (Curiously, the descriptor as a whole matches these attributes insensitively! But confirmed experimentally in JDK 7 that a case-insensitive match does _not_ work on <resources>. Alas.)

2. May have multiple entries separated by spaces (using backslashes to escape spaces within an entry).

3. May match a prefix of the corresponding system property (${} / ${os.arch}).
Comment 11 Quality Engineering 2012-05-04 09:53:52 UTC
Integrated into 'main-golden', will be available in build *201205040400* on (upload may still be in progress)
User: Jesse Glick <>
Log: jnlp.indirect.files useless here since OneModuleClassLoader is not used in JNLP mode anyway. Cf. #76196.