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 157235 - "Top component CoverageReportTopComponent could not be located or loaded from Components folder."
Summary: "Top component CoverageReportTopComponent could not be located or loaded from...
Status: RESOLVED WORKSFORME
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 6.x
Hardware: All All
: P4 blocker (vote)
Assignee: mslama
URL: http://deadlock.netbeans.org/hudson/j...
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-21 14:54 UTC by Jesse Glick
Modified: 2009-04-29 16:13 UTC (History)
0 users

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 2009-01-21 14:54:32 UTC 
########  testJUnit  #######
....
INFO [org.netbeans.core.windows.persistence]: [PersistenceManager.getTopComponentForID] Problem when deserializing
TopComponent for tcID:'CoverageReportTopComponent'. Reason: Top component CoverageReportTopComponent could not be
located or loaded from Components folder.
Comment 1 Torbjorn Norbye 2009-01-21 15:09:41 UTC 
That's odd...

CoverageReportTopComponent contains this:

    @Override
    public int getPersistenceType() {
        return TopComponent.PERSISTENCE_NEVER;
    }

Why would it be serialized/deserialized?
Comment 2 Jesse Glick 2009-01-21 15:23:48 UTC 
Not sure, you'd need to ask a window system expert.
Comment 3 Torbjorn Norbye 2009-01-21 15:36:58 UTC 
Can somebody answer this and then reassign back to python.editor if the bug is on my side? The issue is that Jesse is
getting warnings from windows deserialization for a top component that I've marked with PERSISTENCE_NEVER.
Comment 4 Torbjorn Norbye 2009-01-21 15:39:07 UTC 
P.S. The TopComponent in question is
gsf.codecoverage/src/org/netbeans/modules/gsf/codecoverage/CoverageReportTopComponent.java
Comment 5 mslama 2009-04-23 11:38:35 UTC 
Jesse does it still happen? How to reproduce it?
Comment 6 Jesse Glick 2009-04-23 14:42:36 UTC 
I don't know if it still happens; we are not running IDEValidation on NB-Core-Build any more. I never claimed to be able
to reproduce it, just observed it in the builder's log.
Comment 7 mslama 2009-04-29 16:13:49 UTC 
I do not see this in log of org.netbeans.test.ide.IDECommitValidationTest. If it will happen again I can add callstack
log to see when it happens. Generally when winsys has TC ID it can get TC instance from its internal cache. If it
returns null it tries to deserialize it. It is apparent that if TC is not persistent it is not possible to deserialize
it. Without knowledge where it is called from I cannot say if it is just unimportant warning or if there is any problem.

It is possible that TC is gc'ed but winsys still keeps its TC ID so winsys can anytime try to get TC instance.