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 9272 - httpserver does not release TopManager.systemClassLoader reference
Summary: httpserver does not release TopManager.systemClassLoader reference
Status: CLOSED FIXED
Alias: None
Product: ide
Classification: Unclassified
Component: Internal Server (show other bugs)
Version: 3.x
Hardware: PC Linux
: P4 normal (vote)
Assignee: _ rkubacki
URL:
Keywords:
Depends on: 31504
Blocks: 18613
  Show dependency tree
 
Reported: 2001-01-29 18:33 UTC by Jesse Glick
Modified: 2003-07-01 09:35 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
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 Jesse Glick 2001-01-29 18:33:24 UTC 
In splitloaders, TopManager.systemClassLoader is a dynamic call that can change
after a module uninstall or reinstall. But something in httpserver seems to keep
a strong reference to the systemClassLoader that existed when httpserver was
loaded, which can have bad effects on module reinstallation, as well as being a
potential memory leak.

I think NbServletsInterceptor.java line 35 is to blame, but I am not sure. The
reference seems to be via some servlet mapping.
Comment 1 Jan Chalupa 2001-03-12 10:41:30 UTC 
Version: 'Dev' -> 3.2
Comment 2 Jan Chalupa 2001-05-05 22:33:20 UTC 
Target milestone -> 3.3
Comment 3 _ rkubacki 2001-07-31 09:36:40 UTC 
assigned
Comment 4 Jan Chalupa 2001-11-27 12:40:25 UTC 
Target milestone 3.3.1.
Comment 5 _ rkubacki 2002-03-15 16:58:18 UTC 
see 18613
Comment 6 Jesse Glick 2003-02-26 15:16:20 UTC 
HttpServerModule.ContextReloader seems to be doing this. I can't
really verify since I have no recollection of how I found out that the
systemClassLoader was being retained.

Could perhaps verify better by creating a module with an internal
servlet, then reloading it in test mode repeatedly (running it each
time), ensuring that changes to the code are honored, and using
-J-Dorg.netbeans.core.modules=0 to check that each time the class
loader for the module is reclaimed reliably at some point after it is
uninstalled. I don't really have the time to do this; maybe someone
from QA would like to.
Comment 7 Jesse Glick 2003-02-26 16:36:50 UTC 
In issue #18613, verified that reloading the module uses the new
servlet code. So this is very likely fixed as well, but not directly
confirmed.
Comment 8 Quality Engineering 2003-07-01 09:35:13 UTC 
Resolved for 3.3.x or earlier, no new info since then -> closing.