Possible workaround for DDDataObject might be to use WeakListener but
this doesn't solve the cause.

this is a good hint for 39024 and maybe also for why DataObjects
remain in memory when web/core module is disabled (39095); I will have
to look at this..

Another (possibly related) problem: when the web module gets disabled
the link to web app remain in projects tab (not recognized by loader)
and when web module is enabled again there are 2 links in projects
tab. Disabling web module does not remve the link. When you unmount
web module it removed one link, when you mount it again it 'reuses'
one of the existing links. (unmount/mount eventually removes all links :)

I think this is fixed (Radime please verify). The cause was not in
WebAppObject, as one would think, but in an inner class
WebContextObject.MO that is held in memory by j2eeserver code and was
holding the WebContextObject.

Now it behaves randomly in the IDE - sometimes it works well,
sometimes WEB-INF/classes is left in explorer, sometimes even with
'Duplicate ...' in its name. The good news is that I have reproducible
test commited into web/core/test that creates webmodule, mounts it to
the repository and checks if it can be GC'ed after unmounting. This
test fails always (cf. local FS mount/unmount that passes).

I also tried to mount jsp-examples from Tomcat and unmount leaves
classes+one of mounted JARs in repository :-(

Currently I don't know what is the reason. Suspision -
J2eeProfileSettings listens to server registry and never(?)
deregister. It has Context that keeps the file object and this can
hold whole bunch of objects - DelegatingFS, ExLocalFS, WCO + some other.

The solutio for this problem is not known, the bugfix is potentially
dangerous (in that it can easilly generate regressions). The impact is
limited to two cases: 
1) fix amount of memory is not released after unmounting a web module
2) if there is an open web module and the jsp-servlet module is
disabled the web module nodes will not be removed and user will likely
get exceptions when clicking on them (this is an unlikely scenario) -
the user can still unmount the file system.

The web apps team agrees with waiver. The code will be removed/changed
for the new build system.

I tried to run it in OptimizeIt with its memory leak detector. The
test case was to mount copy of jsp-examples webapp from Tomcat 5
distro (37 JSPs, 38 Java files, 85 class files, 95 html). Only mount /
unmount was perfromed w/ some delay. The bad news is that >1MB is lost
with each iteration. 

Some details:
ServerRegistry keeps J2eeProfileSettings. These have
J2eeDeploymentLoopkup with DConfingBean tied to schema2beans
representation of deployment descriptor. This is a lot of objects.
Also (and this can be worse) J2eeProfileSettings has Context with
reference to FileObject and this is probably how the whole filesystem
is kept.

I would like to see this fixed because the leak is too big and we
should fix this problem with server registry.

Radime, thanks - this is extremely helpful. Looking into code it looks
like J2eeProfileSettings is held by DeploymentTargetImpl (implements
DeploymentTarget) which is held by TargetServer, ServerFileDistributor
and InitialServerFileDistributor. SFD and ISFD implement
ProgressObject and these are _probably_ accidently held by some UI
code in j2eeserver, but I cannot see that far. This code can be
cleaned up but this alone is no more then P3, IMO. I used
WeakReference for J2eeProfileSettings in DeploymentTargetImpl.
Can you confirm this solves the large memmory leak and downgrade to P3?

Thanks Pavel. I tried with current sources (2004-02-18 9:00 CET).

IDE is run on Linux, J2SDK1.4.2_03, empty userdir, memory toolbar
turned on, initialized server registry with Tomcat plugin (by
expanding their nodes) and tried to mount/umount the same web module
as yesterday. Here are numbers from memory toolbar that I get after GCs.

Before: 10.8
1st: 12.7
2nd: 13.2
3rd: 13.7
4th: 13.9
5th: 14.5
6th: 15.1

This seems to be ~500kB per iteration. Better than before but not good
yet.

Some comments to solution: WeakReference may work but often it is a
workaround for API deficiency. Is it the case? Sorry I am too busy too
run profilers at this moment to check what is held now

Here is a bit of update: 
All leaks in j2eeserver for this scenario are resolved (mem diff==0
:-). The mass of memory (yes, .5M as Radim says) is still held by DD
beans. The DDDataObject and related instances are held from 3 places:
- WebContextObject has a listener on classesFS (DelegatingFileSystem)
- DelegatingFileSystem has a FileStatusListener on WebContextObject
- The cache in DDProvider (ddMap) is a weak map but it still does not
release its entries because the fileobjects used a keys never get GCed

All 3 need to be fixed to retake the mem and I am still strugling with
the correct fixes since using WeakListeners makes the unmounting code
unstable which IMO if far worse then the 500k of mem (one or more
filesystems - DFS or jars - are often not unmounted - maybe 30% of
time). The cache in DDProvide could probaly be written with
SoftReferences which would make it possible to occasionally get
cleared but that should not be a big issue (any thoughs on this,
Milane?), for now I was testing by simply not putting anything into it.

I my last comment I made a wrong assumption. The listener to classesFS
in WCO is actually needed and is not harmful for memory. So the fix is
in making the FileStatusListener in DelegatingFileSystem weak and
using weak references in the cache in DDProvider (ddMap) (besides
other small fixes I made earlier in j2eeserver and web module).

As for the cache in DDProvider - the keys in weak map are not GCed so
it does not behave as "weak". I changed it to cache with both weak
keys and values, ie. if nobody is pointing at the value (WebApp) it is
OK to throw it away when there is a GC request. The practical effect
of this is that DD may actually need to be parsed multiple times if
nobody was using it.

I am not 100% sure about the reason why the WEB-XML\xml file is never
released. I susspect it may be fault of XMLDataObject which puts its
non-static innerclass InfoParser into an instance of XMLReader
(org.apache.crimson.parser.XMLReaderImpl) that is held in static
variable of XMLDataObject. Yarda created a diff for me with static
InfoParser but I do not understand the code enough to know when to
release its reference to XMLDataObject or if it is ok to use
WeakReference. If the modification of DDParser cache is not acceptable
Milan and Jarda could possibly follow up on this. Thanks.

Sorry but the test in web/core/test still does not pass (build from
Feb25). I also tried to check memeory meter but was able to repeat the
test more times as there are problems w/ repeated unmounting. 

Radim, how big is the memory leak now? Without this information, the
priority of this issue can not be correctly assessed. Thanks.

16.1
17.5
17.7
18.1
18.1
18.2

After that I tryied to mount/unmount just the WEB-INF/classes folder
several times. The numbers are staying at the same level, at the end
they actually got to 17.9. But some objects are not being GCd during
that so the diff is not zero. I wonder if you have a test for that?

Anyway, other then the first time it is relatively insignificat amount
of memmory. Note that it often takes MANY GC calls to release the
memmory -- I do not know how reliable your test is in this regard.
Also note that after all this testing there are no new objects from
org.netbeans.modules.web.* or o.n.m.j2ee* allocated and not released
in the loop.

Lowering to P3, that also means the 3.6 waiver is not needed as the
main problem was in deed resolved. Please provide more data if you want.

Will not be solved for 3.6. Most of the code will likely be deleted
for promo-D. I am leaving the bug open to verify that.

I am closing this as fixed because there is no web module mounting in
promoD