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 94202 - Provide better life cycle of the insync models (especially FacesModelSet + FacesModels)
Summary: Provide better life cycle of the insync models (especially FacesModelSet + Fa...
Status: NEW
Alias: None
Product: obsolete
Classification: Unclassified
Component: visualweb (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: _ sandipchitale
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-03 00:57 UTC by bugbridge
Modified: 2007-02-03 00:57 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bugbridge 2007-02-03 00:57:49 UTC
Description:
Currently the models in insync (FacesModelSet+FacesModels) are created on 
demand, but then they are destroyed when project is closed, i.e. they are made 
corrupted, no more are working.

This approach is not correct, the models should be available and working until 
they are needed. 

I suggest following approach:
The models to be created on demand (like it is now) and held in the insync by 
weak references (probably the top FacesModelSet only), then they would live 
until the  clients refer (strongly) to them. No explict destoryal (better to 
say corruption) of the models would happen.

The performance issues would be detected by, which clients still refer 
(strongly) to the models, while they are expected not to.

The current impl causes a lot of issues, when e.g. after project is closed 
some components remain open (due to other probable issue), or node still shown 
etc., or other relevant reasons (e.g. there might be changed the impl that the 
components will remain open), then these artifact end up with the corrupted 
unusable model.

Also it causes additional issue, like to handle this destroyal, which is 
completelly unnecessary step.
Also the corruption of the models don't solve the performance issues, it only 
fakes that they are solved, in fact they are not (there might be still 
existing (strong) refs to the models).