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.
in Studio we have CloneableEditorSupportRedirector implementation and due to this fact standard code [1] used from Go To File implementation (org.netbeans.modules.cnd.makeproject.MakeProjectFileProviderFactory) can not open such files. Opening from project view and files view works, but in big project all navigation is done through Go To File with shows only "Loading..." panel instead of editor. Can someone evaluation this? Thanks, Vladimir. [1] Editable ec = od.getLookup().lookup(Editable.class); if (ec != null) { ec.edit(); } else { Openable oc = od.getLookup().lookup(Openable.class); if (oc != null) { oc.open(); } } Now as workaround I have to use: EditorCookie erc = od.getCookie(EditorCookie.class); if (erc != null) { try { try { erc.openDocument(); } catch (UserQuestionException e) { e.confirmed(); erc.openDocument(); } } catch (IOException ex) { Exceptions.printStackTrace(ex); } erc.open(); }
this behavior is reproducible in both versions: trunk and 6.9.1
Integrated into 'main-golden', will be available in build *201011270001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/6cc95196fac1 User: Vladimir Voskresensky <vv159170@netbeans.org> Log: workaround for #192537 - in case of CloneableEditorSupportRedirector files with symlink can't be opened
after change in ces redirector it works fine
Unfortunately change in ces redirector was not enough... it cause infinite recusion for XML objects. It looks like CES Redirector functionality doesn't work. I will attach a simplest test.
Created attachment 105045 [details] module with the simplest ces redirector impl install ces redirector impl from attached module into NB
Created attachment 105046 [details] simple java application to observe issues with ces redirector support in NB extract archive and make sure, that sub folder test has symlinks
steps to reproduce: - unpack provided ces redirector impl module in your trunk source tree - build it (to generate module in extra cluster) - run NB with clean userdir - unpacked JavaApplication2.tar -- make sure subfolder "test" has symlinks after unpack - open JavaApplication2 - expand tests and open file make_project.xml - try to open make_project_link.xml => will be infinite "Loading..." pane - try to open using "Go To File" file make_project_link2.xml => will be infinite "Loading..." pane Test_link.java and file_link.cc should be opened through link correctly. The second problem: - close all files and collapse tests folder, restart NB - if you run with not fresh userdir => make_project_link.xml, make_project_link.xml and make_project_link2.xml will be opened as 3 tabs (instead of one) and by making changes in two files with save symlinks are broken and files are saved as plain files (check content of tests subfolder in console)
Jarda, can you evaluate, please?
Btw, another strange thing is that CESRedirector is called way tooo often. I.e. there is a scheduled task which called by timer and calls isModified which calls CESRedirector. expanding folders in Favorites calls CESRedirector all the time for each file selected in tree. Also it is called when expand folder in favorites
> Behavior could be changed due to introducing "Lazy Loading..." phase > for documents. > Vladimir.
Looks like the condition at CloneableEditor:354 if ((support.getDocument() == null) || (support.cesKit() == null)) is not ready for redirecting. The reason why the problem affects only XML and not Java is that is using CES.asynchronousOpen() = true while XML uses false.
Created attachment 105203 [details] Patch for XML module
The problem with XML is that it has its own implementation of edit() and this implementation does not check for redirection. I've just deleted the method and the redirector started to work OK. I leave up to owner of XML module to decide whether this is an acceptable patch.
Vladimir, can you please indicate if this bug is a Beta stopper or not? I'd also ask you to contact Sergey directly if you are looking for quick resolution.
it's not a Betta stopper
Nikita, please review patch from Jarda
It's a problem to check if the patch effects another XML modules because they are excluded from build procedure. But I think it's acceptable because I think nobody has plan to include them back. Moreover, another XML modules can have similar EditorCookie implementations and they can cause the same bug again.
I am decreasing the priority if it isn't beta stopper.
Nikita, so can Jarda's patch be applied? I agree that the additional XML modules will not be added back, although we may publish them on the update center as there is some user demand for this (issue 184379).
I haven't managed to check if the patch had broken something or not. But I think it can be applied. It only necessary to keep in mind that it can be considered not acceptable later if somebody would like to reanimate XML modules. I don't think it would be the only problem at that moment because I haven't listened that XML modules are developing now. But NetBeans seems is moved forward gradually. So the gap between them becomes wider time after time.
Removing link to CR_7002932 as the issue is now fixed in the Studio IDE.
There is a related CR_7024164
> I haven't managed to check if the patch had broken something or not. I started running XML tests on this Hudson job: http://bertram.netbeans.org/hudson/job/javaee/ (though 16 XML tests are now failing). So after applying the fix, you can check that no additional tests have been broken.
Requesting a waiver for NetBeans 7.0.
Jarda's patch committed to trunk: http://hg.netbeans.org/web-main/rev/8ebb38b41d8c. Still, it should be tested properly before we potentially decide to put it into release70. So the issue should now be fixed in trunk, but I am leaving this issue open because of the pending unresolved waiver request.
This change broke a test: http://bertram.netbeans.org/hudson/job/javaee/lastSuccessfulBuild/testReport/junit/org.netbeans.modules.xml.schema.model/SchemaRefCacheTest/testRedefineSchemaLocationModified/
Integrated into 'main-golden', will be available in build *201103240400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/8ebb38b41d8c User: pjiricka@netbeans.org Log: #192537 - committing patch contributed by Jarda Tulach.
Petr, what is the status of this issue ? Is it waived or ... ?
Yes, waiver is approved.
> This change broke a test: > .../o.n.m.xml.schema.model/SchemaRefCacheTest/testRedefineSchemaLocationModified/ This was actually a random failure, so I think we are ok. The changes were committed to trunk after 7.0, so I believe this is fixed for 7.0.1. Vladimir, can you please verify?
Thanks Petr, I will verify as soon as it appears in cnd-main
Jarda, can you have a look? Now after applied fix => redirector doesn't work and multiple instances of xml files are opened instead of one
My comments are about xml files only. C++ and Java files works fine (as before)
So Vladimir, are you saying the fix caused a regression, and it should be reverted?
Hi Petr, I'm saying, that before fix we had never ending "Loading..." panel instead of editor. Now editors are opened, but each time new tab per opened file (instead of reselecting previously opened tab according to CESRedirector)
Ok, so this is partially fixed. Sounds like with this partial fix, this bug is still P2 priority. So I'd like to request a waiver for NB 7.0.1.
Waiver approved.
Applied cesredirector sample module & tried Java application on 09/15 dev build. Goto file & open action seems to work as expected (open file, do not open multiple windows for the same file). Please verify on a recent dev build.
(In reply to comment #38) > Applied cesredirector sample module & tried Java application on 09/15 dev > build. Goto file & open action seems to work as expected (open file, do not > open multiple windows for the same file). > > Please verify on a recent dev build. I verified using my project attached to this IZ. And all xml files are opened as file in own tab, instead of one tab. While *.cc and *.java files are opened correctly. Note that bug is exactly about links on xml files. So the infinite "Loading..." is gone due to applied patch http://hg.netbeans.org/main/rev/8ebb38b41d8c But original issue is in place: - ces redirector does not work for links to some files (i.e. xml in our case)
I understood the issue is about duplicating windows. However I was unable to reproduce the behaviour on current dev sources (OS Ubuntu Linux) - and using the JavaApplication2 project + cesredirector module attached to this issue. No matter how many times I tried to click on the _link.xml files, subsequent clicks reused the already opened editor. Is there anything other special to be done between two openings of e.g. test/make_project_link.xml ? The affected platform is set to "UNIX"; are you sure the defect is not just solaris-specific ? Which IDE version/build number do you use ?
Thanks for extra evaluation. I've checked on Solaris 10 using today's dev version of IDE
(In reply to comment #41) > Thanks for extra evaluation. > I've checked on Solaris 10 using today's dev version of IDE sorry for posting not finished comment. I've checked on Solaris 10 using today's dev version of IDE and dbl clicking to open files from Project view (Tests folder) open all of them in own tab => 3 tabs
Got it, thanks.
checked on Linux and all 3 files are redirected into one tab
Reproduced even in Linux; the key point is that the editor for the _link file MUST NOT be cached already in the CookieSet (quite random condition ;)). E.g. if the 1st file being opened after IDE start is the link file, it will open in a separate _link tab instead of redirecting to the original.
CloneableEditorSupport added to the DO's lookup; will create/use the same instance as if looking up the OpenCookie.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/d2c100870fae User: sdedic@netbeans.org Log: #192537: CloneableEditorSupport must be registered explicitly, otherwise it might not appear in do.getLookup queries