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 32586 - Wrong cookie returned from FilterNode
Summary: Wrong cookie returned from FilterNode
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Nodes (show other bugs)
Version: 3.x
Hardware: All All
: P1 blocker (vote)
Assignee: Petr Hrebejk
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-04-03 06:31 UTC by Jaroslav Tulach
Modified: 2008-12-22 16:15 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Proposed diff (2.29 KB, patch)
2003-04-03 14:39 UTC, Jaroslav Tulach
Details | Diff
Binary patch for 3.5 to try (28.15 KB, application/octet-stream)
2003-04-03 14:42 UTC, Jaroslav Tulach
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2003-04-03 06:31:36 UTC
If there is a node that implements its cookie
directly:

class N extends AbstractNode implements SaveCookie;

then following code returns invalid results:

new FilterNode (new N ()).getLookup ().lookup
(SaveCookie.class);

This is a general problem which demonstrated
itself in issue 31743 which is P1 for 3.5
Comment 1 Jaroslav Tulach 2003-04-03 06:43:38 UTC
Test to demonstrate the behaviour:
http://www.netbeans.org/source/browse/openide/test/unit/src/org/openide/nodes/NodeLookupTest.java.diff?r1=1.12&r2=1.13
and the fix:
http://www.netbeans.org/source/browse/openide/src/org/openide/nodes/FilterNode.java.diff?r1=1.76&r2=1.77

The problem was in FilterNode always replacing the original node by
itself in returned values. The fix makes difference between "node"
query and other queries. The replacement of nodes is done only for
"node" queries. That way, if somebody asks for SaveCookie, the
original node is returned.

Petr, I think that this is a serious issue and we might want to get it
into 3.5. What do you think, can you do review?


Comment 2 Petr Hrebejk 2003-04-03 14:29:27 UTC
Agree that this is a regression and should be fixed in the release35.
Thus reopening and changing target milestone to 3.5

I think we can go with the current trunk version.
Comment 3 Jaroslav Tulach 2003-04-03 14:39:37 UTC
Created attachment 9680 [details]
Proposed diff
Comment 4 Jaroslav Tulach 2003-04-03 14:42:04 UTC
Created attachment 9681 [details]
Binary patch for 3.5 to try
Comment 5 Jesse Glick 2003-04-03 15:01:33 UTC
Yarda please use -c or -u format for diffs. I just make a ~/.cvsrc:

---%<---
cvs -z3
update -d -P
checkout -P
diff -u
tag -c
---%<---
Comment 6 pzajac 2003-04-04 11:52:54 UTC
I have tested the patch it on linux. It seems fine.
Comment 7 _ ttran 2003-04-04 11:56:21 UTC
approved for 3.5.
Comment 8 Petr Hrebejk 2003-04-04 12:26:25 UTC
Fixed in release 3.5 as well
Comment 9 Marian Mirilovic 2003-04-04 12:31:17 UTC
x
Comment 10 Marian Mirilovic 2003-04-04 12:32:59 UTC
x
Comment 11 Marian Mirilovic 2004-03-15 15:10:56 UTC
fixed long time ago.....
...verified....
reopen if disagree