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 20663

Summary: Set contextClassLoader on all threads to be systemClassLoader
Product: platform Reporter: Jesse Glick <jglick>
Component: Module SystemAssignee: Jesse Glick <jglick>
Status: CLOSED FIXED    
Severity: blocker CC: cliffwd, eakle, lkramolis, phrebejk, ttran
Priority: P2    
Version: 3.x   
Hardware: PC   
OS: Linux   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on:    
Bug Blocks: 17815, 23055, 23399, 24145, 27903    
Attachments: Experimental test that changes in ContextClassLoader are not propagated to child threads - well I could check the sources...
Complete patch for sierra branch

Description Jesse Glick 2002-02-19 13:28:43 UTC
Issue #17815 has a full discussion. Relevant pieces:

jglick:
Making beaninfo into a module may be hard because of the way
Introspector finds classes. I think it needs to be in the same
classloader as the beans.

jtulach:
Introspector uses (amoung others) also Thread.getContextClassLoader.
It seems possible to convince the system to load beaninfos using
SystemClassLoader (together with ThreadGroup.enumerate)...

jglick:
I've thought about contextClassLoader, but it's tricky.
systemClassLoader changes dynamically, so you would need to reset the
contextClassLoader periodically. ThreadGroup.enumerate will give you
all *current* threads but you cannot listen for newly created ones. If
it can be made to work reliably, setting contextClassLoader to
systemClassLoader would probably be useful for a number of libraries;
people sort of expect it to "just work", I think.

jtulach:
Re: contextClassLoader. Each new thread reuses the contextClassLoader
from its parent. So it seems necessary to set the system classloader
for the main thread, all others will inherit it. Plus reset for all
threads in the ThreadGroup when systemCL changes.
Comment 1 Jesse Glick 2002-02-27 18:29:27 UTC
Should also check if this permits lib/ext/rmi-ext.jar to finally be
deleted.
Comment 2 Jaroslav Tulach 2002-03-05 10:01:51 UTC
Created attachment 4936 [details]
Experimental test that changes in ContextClassLoader are not propagated to child threads - well I could check the sources...
Comment 3 Jesse Glick 2002-03-05 11:38:07 UTC
Bummer. Well then I could enumerate all threads, I suppose.

Note that the Java API has an apparent design defect: you have to
decide in advance what size array to make:

http://developer.java.sun.com/developer/bugParade/bugs/4097747.html
Comment 4 Jesse Glick 2002-05-02 17:16:44 UTC
Probably needed for proper JAXP configuration.
Comment 5 Jesse Glick 2002-05-08 21:20:53 UTC
Implemented.

committed   * Up-To-Date  1.26       
core/src/org/netbeans/core/modules/ModuleManager.java
committed   * Up-To-Date  1.16       
core/test/unit/src/org/netbeans/core/modules/ModuleManagerTest.java
committed   * Up-To-Date  1.45       
openide/src/org/openide/TopManager.java
Comment 6 Jesse Glick 2002-05-10 16:00:58 UTC
Libor, please try it out and either verify or reopen as appropriate.
The unit test passes, and a simple manual test (trying to load from
various modules using Thread.currentThread().getContextClassLoader()
from within a Java class run via internal execution) also passes.
Comment 7 _ lkramolis 2002-05-10 16:33:14 UTC
Verified. I have tried to move JAXP/transform API to lib/ext and it
correctly found Xalan's TransformFactory. Thanks.
Comment 8 Jesse Glick 2002-05-10 16:47:41 UTC
Thanks, marking VERIFIED then.
Comment 9 David Strupl 2002-05-15 10:23:38 UTC
*** Issue 23312 has been marked as a duplicate of this issue. ***
Comment 10 David Strupl 2002-05-15 10:28:05 UTC
*** Issue 23312 has been marked as a duplicate of this issue. ***
Comment 11 Jesse Glick 2002-07-25 20:25:01 UTC
Created attachment 6904 [details]
Complete patch for sierra branch
Comment 12 Jesse Glick 2002-07-25 20:31:41 UTC
Committing to sierra as per diff above:

Checking in core/src/org/netbeans/core/modules/ModuleManager.java;
/cvs/core/src/org/netbeans/core/modules/ModuleManager.java,v  <-- 
ModuleManager.java
new revision: 1.17.20.1; previous revision: 1.17
done
Checking in
core/test/unit/src/org/netbeans/core/modules/ModuleManagerTest.java;
/cvs/core/test/unit/src/org/netbeans/core/modules/ModuleManagerTest.java,v
 <--  ModuleManagerTest.java
new revision: 1.10.32.1; previous revision: 1.10
done
Checking in openide/openide-spec-vers.properties;
/cvs/openide/openide-spec-vers.properties,v  <-- 
openide-spec-vers.properties
new revision: 1.38.8.2.4.1.6.1; previous revision: 1.38.8.2.4.1
done

Details:

Pretty much straight merge from trunk (3.4 dev) version, with trivial
syntax corrections to merge from ModuleManagerTest.java, and updating
API spec version so Sierra modules needing this patch can be sure to
depend on

IDE/1 > 1.43.3.1

ensuring they will load in Sierra or 3.4 but be rejected in Orion
(1.43.3).

The unit test passes with the ModuleManager.java patch (and fails
without it, as expected). An ad-hoc test also passes:

System.out.println(Thread.currentThread().getContextClassLoader().loadClass("org.netbeans.modules.java.JavaDataObject"));

(internal execution) prints the Class object, rather than throwing
ClassNotFoundException.

I did not file an integration request for this, sorry - not on SWAN
and apparently not able to log into INF over Sun.Net. Someone else
(Trung, Petr Hr., Cliff, etc.) is welcome to file a pre-closed INF for
this.
Comment 13 Quality Engineering 2003-07-01 16:37:39 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.
Comment 14 Quality Engineering 2008-12-23 14:33:36 UTC
This issue had *2 votes* before move to platform component