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 139051 - Some of core modules are not updatable
Summary: Some of core modules are not updatable
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jiri Rechtacek
URL:
Keywords:
: 138999 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-07-04 16:47 UTC by pslechta
Modified: 2008-12-22 10:23 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
possible patch (1.44 KB, patch)
2008-07-23 16:04 UTC, Jiri Rechtacek
Details | Diff
proposed nbexec patch (3.73 KB, patch)
2008-08-21 13:48 UTC, Jiri Rechtacek
Details | Diff
stacktrace (61 bytes, text/plain)
2008-09-09 13:53 UTC, michel_demazure
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pslechta 2008-07-04 16:47:11 UTC
When updates from UC are applied to core.startup or org.openide.filesystems modules, these modules are not updatable.

Scenario 1: IDE installed by administrator, updates performed by administrator: everything is OK

Scenario 2: IDE installed by administrator, updates performed by non-privileged user (who does not have write
permissions for install dir): modules are stored in user dir, but after restart, old modules from install dir are loaded
and new modules in user dir are ignored.

Scenario 2 is common on Mac and Win Vista platforms. This problem does not allow us to update core modules (NB 6.1 patch
2 was delayed due to this issue). The problem should be solved for NB 6.5 or the problematic modules should be marked as
non-updatable.
Comment 1 Lukas Hasik 2008-07-04 19:27:12 UTC
reassigning to Tonda to decide who will take care about it either module system or plugin manager
Comment 2 Jesse Glick 2008-07-07 15:05:43 UTC
The launcher does not currently support loading such modules from the userdir. If there is no write permission to the
platform cluster, AU should not permit these modules to be updated.
Comment 3 Jesse Glick 2008-07-07 15:32:18 UTC
Could instead consider changing launcher behavior, e.g. for Unix:

diff --git a/o.n.bootstrap/launcher/unix/nbexec b/o.n.bootstrap/launcher/unix/nbexec
--- a/o.n.bootstrap/launcher/unix/nbexec
+++ b/o.n.bootstrap/launcher/unix/nbexec
@@ -403,6 +403,7 @@
     cp=""
     updatercp=""
     
+    build_cp "${userdir}"
     build_cp "${plathome}"
     
     if [ -f "${userdir}/modules/ext/updater.jar" ] ; then

However, that would only affect o.n.boostrap, openide.modules, and openide.util (i.e. lib/*.jar). For core.startup and
openide.filesystems (core/*.jar), you would need to change o.n.MainImpl. Currently it _does_ add
${netbeans.user}/core/*.jar to CP, but after platform's version, so it cannot override those in platform. I'm not sure
why this is so; perhaps Yarda can explain.
Comment 4 Lukas Hasik 2008-07-07 15:55:22 UTC
*** Issue 138999 has been marked as a duplicate of this issue. ***
Comment 5 Antonin Nebuzelsky 2008-07-07 16:01:01 UTC
Note for sustaining: this problem is WONTFIX for 6.1. You have to keep it in mind when producing 6.1 (or older) patches.

For 6.5, we will resolve it. Most probably by changing launchers as Jesse suggests above.
Comment 6 Jiri Rechtacek 2008-07-23 11:55:34 UTC
Confirmed this bug in NB6.1 FCS. I'm going to fix it for NB6.5
Comment 7 Jiri Rechtacek 2008-07-23 16:03:39 UTC
IMHO it's not a bug in Autoupdate code but problem in bootstrap module. Autoupdate correctly install updates into
userdir iff install dir is read-only but updates won't be on classpath. I can confirm Jesse's proposed patch will work
with o.n.bootstrap, openide.modules and openide.util and not for core.startup and openide.filesystems. I could propose a
patch for ModeImpl which makes these module upgradeable as well but it's workaround rather then bugfix. Anyway, the
attached patch can solve the reported problem.
Comment 8 Jiri Rechtacek 2008-07-23 16:04:52 UTC
Created attachment 65403 [details]
possible patch
Comment 9 Jiri Rechtacek 2008-07-23 16:28:33 UTC
Just a note: NetBeans cannot update modules like boot.jar or core.jar in this case of real-only install dirs in ever
releases before (3.x, 4.x or 5.x), it just disallows users to do that. Users have to make the install dirs read/write
and then try it again. It could be the fallback if we won't find the correct fix in MainImpl.
Comment 10 Jesse Glick 2008-07-24 00:12:06 UTC
Your patch looks OK except that BootClassLoader.run already appends ${netbeans.user}/core/*.jar, called as the
runWhenHome param of CLIHandler.initialize, so this would cause such JARs to be added twice to the loader's CP unless
you also change BCL.run to not append those JARs. The convoluted logic is I guess because only CLIOptions (in
core.startup) actually sets netbeans.user from --userdir, but perhaps Yarda can confirm.

Note that CLIOptions also calls FileUtil.normalizeFile on the userdir, which is not possible from MainImpl since it
cannot access FileUtil; not sure if this could be important.
Comment 11 Jiri Rechtacek 2008-07-28 15:05:51 UTC
fixed: rev/dca1ee0c1f6d
nbexec and o.n.boostrap code were fixed. patched nbexec.exe is coming soon.
Comment 12 t_h 2008-07-28 16:27:12 UTC
windows part: 876e6604cf04
Comment 13 Jiri Rechtacek 2008-08-15 14:03:45 UTC
The problem still remains when updating org-openide-filesystems. I'm investigating...
Comment 14 Jiri Rechtacek 2008-08-20 15:17:02 UTC
FYI: Some problems still remains in nbexec.
1) build_cp "${userdir}" is not called after updater run
2) application cp can contain a few times boot.jar
Need to more fixed in nbexec to avoid these problems.
Comment 15 Jiri Rechtacek 2008-08-21 13:47:40 UTC
I'll attach diff of nbexec which solves problem I stated before.
Jesse, please review. The matter of the patch is, construct application classpath again after updater ran and cares to
don't add jar twice in the classpath. Thanks
Comment 16 Jiri Rechtacek 2008-08-21 13:48:25 UTC
Created attachment 68025 [details]
proposed nbexec patch
Comment 17 Jesse Glick 2008-08-23 16:50:45 UTC
  [ -z `echo ${paths} | grep ${subpath}` ]

should probably be replaced with

  echo "$paths" | fgrep -q -v "$subpath"


Get rid of

  echo "*** Added $x"
Comment 18 Jiri Rechtacek 2008-08-26 09:43:19 UTC
Jesse, thanks for review. I'll follow your suggestions and integrated the patch ASAP.
Comment 19 Jiri Rechtacek 2008-08-27 16:26:51 UTC
fixed in nbexec: ab5db07a97bd
Need to fix in windows part also
Comment 20 Quality Engineering 2008-08-28 06:37:06 UTC
Integrated into 'main-golden', available in build *200808280201* on http://bits.netbeans.org/dev/nightly/
Changeset: http://hg.netbeans.org/main/rev/ab5db07a97bd
User: Jiri Rechtacek <jrechtacek@netbeans.org>
Log: #139051: Some of core modules are not updatable
Comment 21 t_h 2008-09-04 15:23:20 UTC
Windows launcher part in 14b440a5f2cc
Comment 22 Quality Engineering 2008-09-05 06:11:46 UTC
Integrated into 'main-golden', will be available in build *200809050201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/14b440a5f2cc
User: Tomas Holy <t_h@netbeans.org>
Log: #139051: Some of core modules are not updatable (Windows part in launcher)
Comment 23 michel_demazure 2008-09-09 13:52:56 UTC
Build: NetBeans IDE Dev (Build 200809071401)
VM: Java HotSpot(TM) Client VM, 1.6.0_02-b06, Java(TM) SE Runtime Environment, 1.6.0_02-b06
OS: Windows Vista, 6.0, x86

User Comments: 


Stacktrace: 
java.lang.NoClassDefFoundError: org/netbeans/updater/XMLUtil
Comment 24 michel_demazure 2008-09-09 13:53:01 UTC
Created attachment 69402 [details]
stacktrace