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.
Debugger uses RequestProcessor.getDefault().post (Runnable) in JPDAStart ANT task to start debugging sessions. When executing the Runnable object in a RP thread, the context classloader is sometimes set to org.apache.tools.ant.module.bridge.AntBridge$AllPe rmissionURLClassLoader. Since the code runs in a RP thread, we expect it to be a NB system classloader. This issue prevents resourse lookups, etc.
Please note that issue #41280 is a Q-build stopper. If the analysis is correct, this needs to be resolved asap.
understood, but Jesse is probably packing his luggage or even already on his way to the airport and Nejedly is on vacation. I can't guarantee they can look at this before next Monday
Well, the Ant module is correctly setting the context class loader to be Ant's loader for all Ant tasks. This is required for many Ant tasks to behave correctly. What calls you make within the Ant task is irrelevant; if you are running inside the thread group that corresponds to the Ant run, that is what the context loader will be. AFAIK there is no documented contract that RequestProcessor must run tasks in any particular thread or thread group. It *could* create new threads in the system thread group, regardless of the caller's location, but I think this would be undesirable in general; for one thing, it would prevent the execution engine from reliably knowing when a task using RP had fully completed. RequestLevel.Processor does call super with getTopLevelThreadGroup (apparently this is not working) but I don't what the original justification for this was, and I tend to disagree with it. If you temporarily need a different context class loader for whatever reason, set one yourself, and be sure to reset it in a finally block: ClassLoader desiredCCL = ...; Thread t = Thread.currentThread(); ClassLoader origCCL = t.getContextClassLoader(); t.setContextClassLoader(desiredCCL); try { // whatever you need to do } finally { t.setContextClassLoader(origCCL); } Anyway you should avoid relying on the context class loader in most cases. For "resource lookup" (details??), please use Class.getResource(String) or NbBundle variants taking a Class argument, which are insensitive to the context class loader. There are a few situations where some library code you do not control, e.g. JAXP, requires the CCL to be set in a certain way; in such cases use the idiom above to set it to what you need for the dynamic scope you require.
closed