Bug 205653 - NPE: [org.netbeans.modules.netbinox]: framework event org.eclipse.mylyn.commons.net type 2
NPE: [org.netbeans.modules.netbinox]: framework event org.eclipse.mylyn.commo...
Status: VERIFIED FIXED
Product: platform
Classification: Unclassified
Component: Netigso
7.1
All All
: P3 (vote)
: 7.1
Assigned To: Jaroslav Tulach
issues@platform
: 71_HR_FIX, REGRESSION, TEST
: 205713 206132 (view as bug list)
Depends on: 197066
Blocks: 205019
  Show dependency treegraph
 
Reported: 2011-11-29 13:57 UTC by Jiri Skrivanek
Modified: 2011-12-19 08:08 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
IDE log. (61.01 KB, text/plain)
2011-11-29 13:57 UTC, Jiri Skrivanek
Details
testWriteAccess - stack trace (6.93 KB, text/plain)
2011-12-01 15:20 UTC, Jiri Skrivanek
Details
new patch without changes to apisupport.harness (8.75 KB, patch)
2011-12-01 16:19 UTC, Jaroslav Tulach
Details | Diff
New patch with apichanges.xml (9.40 KB, patch)
2011-12-01 16:42 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Skrivanek 2011-11-29 13:57:01 UTC
Created attachment 113616 [details]
IDE log.

Chain of exceptions is thrown when running UI commit validation tests. The class IDECommitValidationTest is in java.kit module. Full stack trace in attached messages.log.

SEVERE [org.netbeans.modules.netbinox]: framework event org.eclipse.mylyn.commons.net type 2
java.lang.NullPointerException

Caused: org.osgi.framework.BundleException: Exception in org.eclipse.core.internal.net.Activator.start() of bundle org.eclipse.core.net.

Caused: org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException: An error occurred while automatically activating bundle org.eclipse.core.net (81).

Caused: java.lang.NoClassDefFoundError: org/eclipse/core/net/proxy/IProxyService

Caused: org.osgi.framework.BundleException: Exception in org.eclipse.mylyn.internal.commons.net.CommonsNetPlugin.start() of bundle org.eclipse.mylyn.commons.net.
Comment 1 Antonin Nebuzelsky 2011-11-29 15:47:33 UTC
Not for 7.1?
Comment 2 Jaroslav Tulach 2011-11-29 21:23:25 UTC
Could be fixed by passing in startupArguments("--branding", "nb"), there is a bug 197066 to use this parameter automatically.
Comment 3 Jiri Skrivanek 2011-11-30 09:33:09 UTC
It appears in new 7.1 RC2 build 201111292200 (#6ac84b6073e5). Not reproducible in previous RC1 build 201111242103 (#0845e53258a4).
Comment 4 Jaroslav Tulach 2011-12-01 09:58:21 UTC
Caused by fix of bug 205019 - that is why it is not in RC1. I'd like to fix it by fixing bug 197066, but that needs some time. If there is just one failing test, then I suggest to fix it by adding addStartupArgument("--branding", "nb") to the test's initialization.

See http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-nbjunit/org/netbeans/junit/NbModuleSuite.Configuration.html#addStartupArgument(java.lang.String...)

Jirko, you can fix it in release71 and leave it failing in trunk, imho. Then pass it back to me.
Comment 5 Tomas Stupka 2011-12-01 10:12:20 UTC
*** Bug 205713 has been marked as a duplicate of this bug. ***
Comment 6 Jiri Skrivanek 2011-12-01 10:42:45 UTC
Adding addStartupArgument("--branding", "nb") helps. But I think this exception
appears whenever someone runs test using NbModuleSuite, doesn't it? Especially
platform developers can face this issue. Would it be possible to rather somehow
suppress/catch this exception in 7.1?
Comment 7 Jesse Glick 2011-12-01 14:17:30 UTC
(In reply to comment #6)
> I think this exception
> appears whenever someone runs test using NbModuleSuite, doesn't it? Especially
> platform developers can face this issue.

Only if they are using the ide cluster, I think - that is where org.eclipse.equinox.security lives.
Comment 8 Jaroslav Tulach 2011-12-01 14:20:01 UTC
This is a patch that fixes the problem for me:
http://bugzilla-attachments-197066.netbeans.org/bugzilla/attachment.cgi?id=113705

Especially its following part should go into 7.1 release. Without it even users of the IDE could see the NPE under some circumstances:

diff -r f5508ddfc576 o.eclipse.equinox.common/nbproject/project.properties
--- a/o.eclipse.equinox.common/nbproject/project.properties	Thu Dec 01 08:50:37 2011 +0100
+++ b/o.eclipse.equinox.common/nbproject/project.properties	Thu Dec 01 15:15:11 2011 +0100
@@ -1,3 +1,5 @@
 release.external/org.eclipse.equinox.common-3.6.0.jar=modules/org-eclipse-equinox-common.jar
 is.autoload=true
 nbm.module.author=Tomas Stupka
+module.startlevel=2


The patch also includes changes to apisupport.harness which may not be necessary for 7.1, Jesse please review. 

The patch does not check behavior of binary test distribution. QA please verify its behavior.
Comment 9 Jiri Skrivanek 2011-12-01 15:16:45 UTC
I tried the patch in trunk and the exception was never thrown regardless I run IDECommitValidationTest from the IDE or using binary distribution. When running from binary distribution testWriteAccess failed (see attached stack trace) but it seems unrelated.
Comment 10 Jiri Skrivanek 2011-12-01 15:20:48 UTC
Created attachment 113711 [details]
testWriteAccess - stack trace
Comment 11 Jaroslav Tulach 2011-12-01 15:29:22 UTC
Yes, the failure is not related. It is caused by autoupdate kicking in after 15/30s and trying to do something. Best to modify the test to ignore this write attempt.
Comment 12 Jesse Glick 2011-12-01 15:36:11 UTC
(In reply to comment #8)
> +module.startlevel=2

OK as far as I am concerned; it seems reasonable that this core-sounding module should have a lower start level (2) than others (4).

The one problem I can foresee is in an app which does not define a default start level for bundles yet uses Equinox bundles from the ide cluster, since a level of 2 will be higher than the default (right?). However o.eclipse.equinox.registry is already at 3 so such an app would just have to define a default level like the NB IDE does (and o.eclipse.equinox.common probably needs a strictly lower level than others to avoid random errors). Possibly the start level system should behave more sensibly out of the box so that 4 is automatically used as a default level (without any special branding) when Equinox rather than Felix is in use, though I am unsure whether this really make sense and how it would affect JDev or other cases; not for 7.1 anyway.

> The patch also includes changes to apisupport.harness which may not be
> necessary for 7.1

Those are already discussed in a separate issue (and I do not agree with some parts of that patch). For 7.1 it should suffice to just patch IDEValidation to explicitly set --branding nb.
Comment 13 Jaroslav Tulach 2011-12-01 16:19:00 UTC
Created attachment 113714 [details]
new patch without changes to apisupport.harness

As all our tests using NbModuleSuite throw the same exception, I'd rather fix them all - e.g. make sure that NetBeans.org projects are running with nb branding.
Comment 14 Jaroslav Tulach 2011-12-01 16:42:38 UTC
Created attachment 113716 [details]
New patch with apichanges.xml
Comment 15 Jaroslav Tulach 2011-12-01 16:43:37 UTC
So in summary for 7.1: bug #197066 will be partly fixed (NbModuleSuite, projectized.xml, but no common.xml or apisupport.harness changes); #205653 will be fixed with an additional patch to o.eclipse.equinox.common startlevel (will commit as separate patch).
Comment 16 Jaroslav Tulach 2011-12-01 17:35:41 UTC
ergonomics#4edff56ac7d8

merged into release71 as 1dc1b1aa3207
Comment 17 Quality Engineering 2011-12-04 11:59:24 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/4edff56ac7d8
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #205653: Always specify 'nb' as branding for netbeans.org NbModuleSuite tests
Comment 18 Petr Cyhelsky 2011-12-06 08:00:25 UTC
Still getting this exception in org.netbeans.test.profiler/ProfilerValidationTest/testProfilerMenus -> Reopening

as it seems to be fixed for most cases -> lowering priority
Comment 19 Jaroslav Tulach 2011-12-15 10:14:32 UTC
This bug is fixed in the IDE. If you see it in tests, it may be because you don't have all necessary modules enabled. Definitely it is different bug.
Comment 20 Jaroslav Tulach 2011-12-15 10:15:29 UTC
*** Bug 206132 has been marked as a duplicate of this bug. ***
Comment 21 Jiri Skrivanek 2011-12-19 08:08:11 UTC
Filed bug 206468 for not yet fixed cases.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo