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 - Set contextClassLoader on all threads to be systemClassLoader
Summary: Set contextClassLoader on all threads to be systemClassLoader
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 3.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: Jesse Glick
: 23312 (view as bug list)
Depends on:
Blocks: 17815 23055 23399 24145 27903
  Show dependency tree
Reported: 2002-02-19 13:28 UTC by Jesse Glick
Modified: 2008-12-23 14:33 UTC (History)
5 users (show)

See Also:
Exception Reporter:

Experimental test that changes in ContextClassLoader are not propagated to child threads - well I could check the sources... (1.72 KB, text/plain)
2002-03-05 10:01 UTC, Jaroslav Tulach
Complete patch for sierra branch (9.55 KB, patch)
2002-07-25 20:25 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2002-02-19 13:28:43 UTC
Issue #17815 has a full discussion. Relevant pieces:

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.

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

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.

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
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:
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

committed   * Up-To-Date  1.26       
committed   * Up-To-Date  1.16       
committed   * Up-To-Date  1.45       
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/;
/cvs/core/src/org/netbeans/core/modules/,v  <--
new revision:; previous revision: 1.17
Checking in
new revision:; previous revision: 1.10
Checking in openide/;
/cvs/openide/,v  <--
new revision:; previous revision:


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

IDE/1 >

ensuring they will load in Sierra or 3.4 but be rejected in Orion

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


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

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
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