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 244326 - WARNING [org.netbeans.ProxyClassLoader]: Will not load class org.netbeans.core.startup.RunLevel arbitrarily from one of org.netbeans.MainImpl$BootClassLoader@abd40ef and ModuleCL@36b4366b[org.netbeans.modules.autoupdate.services] starting from SystemClass
Summary: WARNING [org.netbeans.ProxyClassLoader]: Will not load class org.netbeans.cor...
Status: STARTED
Alias: None
Product: apisupport
Classification: Unclassified
Component: Maven (show other bugs)
Version: 8.0
Hardware: PC Windows 7
: P3 normal (vote)
Assignee: Milos Kleint
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-06 10:58 UTC by chrislovsund
Modified: 2014-06-05 18:02 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
example project, mvn clean install on parent should give error (17.59 KB, application/octet-stream)
2014-05-06 10:58 UTC, chrislovsund 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description chrislovsund 2014-05-06 10:58:46 UTC 
Created attachment 147132 [details]
example project, mvn clean install on parent should give error

We have a lot of functional tests that use JellyTestCase.
 
A module has dependency on [org.netbeans.modules.autoupdate.services] 


WARNING [org.netbeans.ProxyClassLoader]: Will not load class org.netbeans.core.startup.RunLevel arbitrarily from one of org.netbeans.MainImpl$BootClassLoader@5622f08f and ModuleCL@723fff84[org.netbeans.modules.autoupdate.services] starting from SystemClassLoader[81 modules]; see http://wiki.netbeans.org/DevFaqModuleCCE
WARNING [org.openide.util.lookup.MetaInfServicesLookup]: org.netbeans.core.startup.RunLevel could not be found in SystemClassLoader[81 modules]
WARNING [org.openide.util.lookup.MetaInfServicesLookup]: org.openide.LifecycleManager is not the real McCoy! Actually found it in ModuleCL@723fff84[org.netbeans.modules.autoupdate.services] (from SystemClassLoader[81 modules]) but searched for from java.net.URLClassLoader@72a32604

and window is not shown. 

I created a small example project that get the same error.
Comment 1 chrislovsund 2014-05-06 11:04:35 UTC 
same issue found on forum:
https://forums.netbeans.org/viewtopic.php?p=157363
Comment 2 Jaroslav Tulach 2014-05-09 10:16:51 UTC 
The system believes that org.netbeans.modules.autoupdate.services module is consisting from 9 JARs:

[/tmp/org-netbeans-modules-autoupdate-services-RELEASE80-1243190268654427715.jar, /tmp/org.netbeans.api-org-openide-filesystems-RELEASE80-5800127656499548322.jar, /tmp/org.netbeans.api-org-openide-modules-RELEASE80-7201373842669490096.jar, /tmp/org.netbeans.api-org-openide-util-RELEASE80-4466675180584607872.jar, /tmp/org.netbeans.modules-org-netbeans-core-startup-RELEASE80-2708597717331708252.jar, /tmp/org.netbeans.api-org-netbeans-api-progress-RELEASE80-5508953531429307531.jar, /tmp/org.netbeans.api-org-openide-util-lookup-RELEASE80-1245865797703145304.jar, /tmp/org.netbeans.external-updater-RELEASE80-6331045196496793407.jar, /tmp/org.netbeans.modules-org-netbeans-bootstrap-RELEASE80-5102156085381473190.jar]

it is not. The org.openide.filesystems should not be listed here.
Comment 3 Jaroslav Tulach 2014-05-09 10:23:06 UTC 
The classpath attribute of the module contains 

org.netbeans.api-org-netbeans-api-progress-RELEASE80-722716134522898708.jar org.netbeans.modules-org-netbeans-bootstrap-RELEASE80-618668022233416864.jar org.netbeans.modules-org-netbeans-core-startup-RELEASE80-4060474343084440844.jar org.netbeans.api-org-openide-filesystems-RELEASE80-1587362243469764956.jar org.netbeans.api-org-openide-modules-RELEASE80-4472665332871589395.jar org.netbeans.api-org-openide-util-RELEASE80-2953244308685221132.jar org.netbeans.api-org-openide-util-lookup-RELEASE80-768375114494006416.jar org.netbeans.external-updater-RELEASE80-2657072228719533928.jar

this will be bug in NbJUnit or Maven.
Comment 4 chrislovsund 2014-05-09 11:09:03 UTC 
Ok, anything I should do to speed things up?
Comment 5 Jaroslav Tulach 2014-05-09 11:40:29 UTC 
Maven-Class-Path of 
http://bits.netbeans.org/nexus/content/groups/netbeans/org/netbeans/api/org-netbeans-modules-autoupdate-services/RELEASE80/
seems to be 

org.netbeans.api:org-netbeans-api-progress:RELEASE80 org.netbeans.modules:org-netbeans-bootstrap:RELEASE80 org.netbeans.modules:org-netbeans-core-startup:RELEASE80 org.netbeans.api:org-openide-filesystems:RELEASE80 org.netbeans.api:org-openide-modules:RELEASE80 org.netbeans.api:org-openide-util:RELEASE80 org.netbeans.api:org-openide-util-lookup:RELEASE80 org.netbeans.external:updater:RELEASE80

I think this is not correct (maybe caused by updater.jar being part of the project). Then the NbModuleSuite

http://hg.netbeans.org/releases/annotate/0c2ea0735707/nbjunit/src/org/netbeans/junit/NbModuleSuite.java#l1139

duplicates these JARs on classpath. As the NbModuleSuite code has been written as part of bug 190992 I am moving this to Maven guys. The whole Maven-Class-Path is a mystery to me, but it is clear it needs to work in orchestration.
Comment 6 Jaroslav Tulach 2014-05-09 11:52:36 UTC 
The workaround is to exclude autoupdate.services from the application (or at least from the module that does the integration testing). Following diff makes the original project execute tests OK:


diff -r 6b796d1c58b2 application/pom.xml
--- a/application/pom.xml       Fri May 09 13:47:25 2014 +0200
+++ b/application/pom.xml       Fri May 09 13:50:51 2014 +0200
@@ -50,6 +50,12 @@
             <groupId>${project.groupId}</groupId>
             <artifactId>MavenNetbeansApp-sample</artifactId>
             <version>${project.version}</version>
+            <exclusions>
+                <exclusion>
+                    <groupId>org.netbeans.api</groupId>
+                    <artifactId>org-netbeans-modules-autoupdate-services</artifactId>
+                </exclusion>
+            </exclusions>
         </dependency>
     </dependencies>
 
@@ -58,6 +64,9 @@
             <plugin>
                 <groupId>org.codehaus.mojo</groupId>
                 <artifactId>nbm-maven-plugin</artifactId>
+                <configuration>
+                    <verifyIntegrity>false</verifyIntegrity>
+                </configuration>
             </plugin>
             <!-- Permits NbModuleSuite to be run in integration-test phase: -->
             <plugin>
Comment 7 Milos Kleint 2014-05-15 11:33:46 UTC 
> The whole Maven-Class-Path is a mystery to me, but it is clear it needs to work in orchestration.

at some point in time we added ClassPath to the module project's jar in repository. However that was causing trouble when running unit tests and basically anything else not inside netbeans container. because the classpath jars are rarely at the correct position. So now we have Maven-Class-Path in the jar and it's only converted to Class-Path right before it ends up in the nbm file.
Comment 8 chrislovsund 2014-06-05 18:02:43 UTC 
It didn't work for our big real project to just exclude dependency on <artifactId>org-netbeans-modules-autoupdate-services</artifactId>, since it needs it. I ended up using modified jar without Maven-Class-Path in manifest.mf

<dependency>
   <groupId>org.netbeans.api</groupId>
   <artifactId>org-netbeans-modules-autoupdate-services</artifactId>
   <version>RELEASE80</version>
   <classifier>ifs</classifier>
   <scope>test</scope>
</dependency>

btw, we also need to do the same for org-netbeans-modules-javahelp, for both RELEASE72 and RELEASE80

<dependency>
    <artifactId>org-netbeans-modules-javahelp</artifactId>
    <groupId>org.netbeans.api</groupId>
    <version>${netbeans.version}</version>
    <classifier>ifs</classifier>
    <scope>test</scope>
</dependency>