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.
Should also check if this permits lib/ext/rmi-ext.jar to finally be
Created attachment 4936 [details]
Experimental test that changes in ContextClassLoader are not propagated to child threads - well I could check the sources...
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:
Probably needed for proper JAXP configuration.
committed * Up-To-Date 1.26
committed * Up-To-Date 1.16
committed * Up-To-Date 1.45
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.
Verified. I have tried to move JAXP/transform API to lib/ext and it
correctly found Xalan's TransformFactory. Thanks.
Thanks, marking VERIFIED then.
*** Issue 23312 has been marked as a duplicate of this issue. ***
Created attachment 6904 [details]
Complete patch for sierra branch
Committing to sierra as per diff above:
Checking in core/src/org/netbeans/core/modules/ModuleManager.java;
new revision: 188.8.131.52; previous revision: 1.17
new revision: 184.108.40.206; previous revision: 1.10
Checking in openide/openide-spec-vers.properties;
new revision: 220.127.116.11.18.104.22.168; previous revision: 22.214.171.124.4.1
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
IDE/1 > 126.96.36.199
ensuring they will load in Sierra or 3.4 but be rejected in Orion
The unit test passes with the ModuleManager.java 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
Resolved for 3.4.x or earlier, no new info since then -> closing.
This issue had *2 votes* before move to platform component