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.
Product Version: NetBeans IDE Dev (Build 200910290252) Java: 1.6.0_16; Java HotSpot(TM) Client VM 14.2-b01 System: Linux version 2.6.28-16-generic running on i386; UTF-8; en_US (nb) 1) open pom.xml in editor either from Go To File wizard or from Explorer 2) double-click on any item of the POM model view of the pom.xml in Navigator 3) -> the same pom.xml is opened in a second editor tab and cursor is moved to the item's position there 4) go back to the first pom.xml editor 5) double-click on any other item in Navigator 6) -> focus is changed again to the second pom.xml editor and navigation happens there
hmm.. this could be somehow related to the "cannot save edited pom file" problem. It seems something somewhere changed and we get 2 editors/documents for the same thing maybe?
reassigning to platform/text. Please for reasoning see issue 175277, it could be effectively a duplicate of that one. This one is 100% reproducible given the steps in description.
Not sure what could cause this but I cannot reproduce with my latest build from core-main when I follow steps. Please retest. Only one editor stays opened. I created sample Maven project Maven Calculator Service. Or is it specific to some project only? In such case please attach test project.
It started to happen to me too. Investigating.
I tried today's build and first it seemed like it is not happening any more, but then I switched back to the older build and back to the new one and now I see it with both, most of the time.
2 instances of DataEditorSupport are created. Passing to data systems. I will attach call stacks.
Created attachment 90304 [details] Call stacks
DataObject instance is the same
P2 is duplicate of this issue.
*** Issue 175277 has been marked as a duplicate of this issue. ***
Simulated in following test: diff -r 23804ead259f xml/test/unit/src/org/netbeans/modules/xml/XMLDataObjectTest.java --- a/xml/test/unit/src/org/netbeans/modules/xml/XMLDataObjectTest.java Tue Nov 03 06:21:21 2009 +0300 +++ b/xml/test/unit/src/org/netbeans/modules/xml/XMLDataObjectTest.java Tue Nov 03 11:28:34 2009 +0100 @@ -42,6 +42,7 @@ import java.io.IOException; import org.netbeans.junit.NbTestCase; +import org.openide.cookies.EditorCookie; import org.openide.filesystems.FileObject; import org.openide.filesystems.FileUtil; import org.openide.loaders.DataObject; @@ -76,5 +77,11 @@ XMLDataObject dataObject = (XMLDataObject) object; assertNotNull(dataObject.getLookup().lookup(FileObject.class)); + + EditorCookie ec = dataObject.getCookie(EditorCookie.class); + assertNotNull("Editor cookie found", ec); + + EditorCookie lkp = dataObject.getLookup().lookup(EditorCookie.class); + assertEquals("Cookies are the same", ec, lkp); } }
Looks like a bug in CookieSet.
core-main#2c07cc308ffb
*** Issue 175776 has been marked as a duplicate of this issue. ***
Integrated into 'main-golden', will be available in build *200911041401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/2c07cc308ffb User: Jaroslav Tulach <jtulach@netbeans.org> Log: #175750: Sharing the CookieEntry between cookie and lookup to let only one instance be created by the factory
Unfortunately I can still reproduce with build 200911041401.
Various cookies of XMLDataObject subclass are duplicated. I guess the cleanest solution is to enhance the API.
Created attachment 90521 [details] The api change and its usage in xml
Guys, give me explicit go, so I can integrate on Monday Nov 9, 2009. Thanks.
Looks OK to me.
I haven't tested the patch but one thing sounds strange here to me.. The maven support doesn't have it's own dataobject. we use the default xml one, so how did duplicates ended up there in the first place?
For historical reasons there are two XMLDataObjects. org.openide.loaders.XMLDataObject and org.netbeans.modules.xml.XMLDataObject. The later subclasses the first and tries to override its CloneableEditorSupport functionality using some wild tricks that do not work reliably. The API just allows the subclass to disable CES registration in super class, so no tricks are necessary anymore.
No comment. => Go.
OK, let's do it.
core-main#35e736c73924
*** Bug 177706 has been marked as a duplicate of this bug. ***