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 118017 - jnlp.sign.jars and jnlp.platform.codebase do not mix
Summary: jnlp.sign.jars and jnlp.platform.codebase do not mix
Alias: None
Product: apisupport
Classification: Unclassified
Component: Harness (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: pgebauer
Depends on:
Blocks: 98371
  Show dependency tree
Reported: 2007-10-06 22:26 UTC by Jesse Glick
Modified: 2015-09-09 11:22 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2007-10-06 22:26:57 UTC
In my experiments, jnlp.sign.jars=false does not work when using jnlp.platform.codebase (set to a local file: codebase,
as generated by nbbuild/build.xml#build-jnlp). javaws complains that an unsigned JAR (e.g. swing-layout-*, which
is not even executable code) is requesting full access. startup.jar's Main does not seem to have been run yet (e.g.
inserting a call to JOptionPane.showMessageDialog does nothing).

Things work if the platform *.jnlp & *.jar are moved physically inside the codebase of master.jnlp (and their codebases
rewritten accordingly), which I guess is why j.s.j=f works if j.p.c is not specified (since then the platform JNLPs/JARs
are generated in a netbeans/ subdir).

Should either be fixed, if possible (I have no idea if it is); or at least jnlp.xml should abort with a friendly message
saying that the combination will not work.
Comment 1 Jesse Glick 2007-10-06 22:41:29 UTC
Note: when using codebase, it works, I guess
since these JARs are signed. (Though it is _slow_.) To reproduce, in a dev build make a suite with a simple module w/
one TopComponent. Set to app mode, accept default module excludes. Then run

ant -f ..../nbbuild/build.xml build-jnlp -Djnlp.sign.jars=false
ant -f ..../suite/build.xml clean build-jnlp run-jnlp -Djnlp.platform.codebase=file:..../nbbuild/build/jnlp/
Comment 2 David Strupl 2007-10-23 14:15:28 UTC
Just before I start looking at this can you please answer this: why do you call build-jnlp from the nbbuild at all? I
was always using just the call from the suite's directory. It packaged the platform jnlp nicely in the suite's dist
folder ...
Comment 3 Jesse Glick 2007-10-24 00:11:44 UTC
suite.xml#build-jnlp (without jnlp.platform.codebase) is a minimal implementation which is hacked up just enough to work
on the current platform cluster. It treats all target platform modules uniformly and has a special-cased excludes list
for some ignorable files. It does not work at all on other clusters or with arbitrary modules which sometimes need
special treatment. nbbuild/build.xml#build-jnlp calls the jnlp target in each module, which (1) can use special
properties such as jnlp.verify.excludes and jnlp.indirect.jars which are defined by the module rather than the harness,
or (2) even have custom implementation (as e.g. ant or extbrowser modules). If we shipped *.jnlp files as part of the
binary platform then we would always use those and there would be no problem, but it is an unfortunate fact that we do
not ship them; so Yarda made this system in which we actually have two, subtly different, ways of including the platform
in a JNLP app.
Comment 4 Jesse Glick 2009-10-23 23:25:53 UTC
Regarding last comment, see issue #70477 for more detail.
Comment 5 Jesse Glick 2010-03-11 12:05:40 UTC
Not possible for 6.9.
Comment 6 Jaroslav Tulach 2012-11-05 15:10:41 UTC
Who needs this?
Comment 7 Jesse Glick 2012-11-05 18:28:13 UTC
If it is not going to be fixed, the documentation should explain that.
Comment 8 Jaroslav Tulach 2012-12-06 08:15:31 UTC
What documentation and what should I put there?
Comment 9 Jesse Glick 2012-12-06 19:13:02 UTC
harness/README documents jnlp.sign.jars; should be more emphatic that this option only works under special circumstances, and generally not when jnlp.platform.codebase is used. Not solvable until *.jnlp descriptors are treated as first-class binary artifacts.