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.
use this code in JSP file: ------------------------ <%@page import="java.util.Data"%> <%! String message = new Date().toString(); %> -------------------- two errors are shown -> invalid import, invalid constructor change "java.util.Data" to "java.util.Date" -> error should be fixed, but its mark doesn't disappear do more typing - errors are still visible. The only way to update errors is saving the document
Was this assigned to me on purpose? I don't mind fixing it or having a look where is the problem. It still does not work.
Looks like parsing.api versus JSP parser synchronization issue. These two parsers are not synchronized, but in fact the parsing.api java parser depends on jsp parser. To be able to properly generate the java virtual source (for example beans, imports etc.) the java embedding provider (making the "simplified jsp servlet body") needs the jsp parser result. However when the file is modified the parsing.api tasks runs faster than the jsp parser, so if you modify something which is important for the virtual servlet and is obtained from jsp parser you will see the change after next parsing round of the parsing.api parser. To verify this simply modify the Data to Date and wait ... parsing.api wheel starts rolling ... simplified jsp servlet is generated ... then jsp parser finishes. You can still see the error. Then do a simple modification - add a whitespace somewhere ... parsing.api wheel rolls again ... simplified jsp servlet is regenerated, BUT with the proper previously created jsp parsing data ... and the error is gone. Sure this is all wrong, there needs to be some synchronization between these two. Since I plan to migrate the jsp parser to parsing.api in next version I wouldn't loose to much time with this. OTOH when the jsp parser finishes it fires revalidate event to the token hierarchy so if the parsing.api listened properly on tokenhierarchy all its tasks would rerun. Even if we had this there would still be an inefficiency in running the parsing.api tasks twice where the first run is just waste of time. Although this inefficiency happens only if you modify something in the jsp which causes the parsing data to change (the parser change is fired only on changes of the metadata). I remember I saw or even filed an issue to parsing api about the token hierarchy listening so maybe doing the fix (I suppose simple) would help quite a lot.
Re. "if the parsing.api listened properly on tokenhierarchy all its tasks would rerun" - sounds like right solution for this release.
I doublechecked the issue and it looks like the EventSupport$DocListener from parsing api does the right job and the problem is on jsp side. When the jsp parser finishes parsing JspColoringData.applyParsedData() method is called. It check if on of following things changed from the last successful parser run: 1) list of taglibs 2) list of custom tag prefixes 3) if the file is jsp syntax 4) if EL is ignored in the file The rest of the parser result content is ignored so even if it is changed the change event is not fired and hence the JspKit$LexerColoringListener is not notified and doesn't rebuild the token hierarchy. Looks like the simpliest fix is to fire the change event every time, better one is to also compare the list of declared beans, imports and other stuff affecting the SimplifiedServlet generation. I'll try to do #2 tomorrow, in the worst case #1. Sorry for blaming the parsing api. I really had an impression it didn't work the way it works now before some time. BTW the issue I mentioned was filed against Schlieman and already fixed - issue #149994
*** Issue 166963 has been marked as a duplicate of this issue. ***
*** Issue 173552 has been marked as a duplicate of this issue. ***
The behavior is improved in NB 6.8 dev build: after correcting Data -> Date, the mark still does not disappear, but after more typing, it does. Saving is not necessary any more, it's enough to continue typing. Jindro, can we downgrade to P4?
Nono, saving hasn't been necessary ever. What you describe is the state which is known to me and is described in detail in one of my longer descriptions. I bet nothing changed to this issues. And finally, I wouln't downgrade, rather upgrade. It's really nasty bug which should be fixed, but as you know the fix is really tricky.
*** Issue 160113 has been marked as a duplicate of this issue. ***
Upgrading to P2, as the user impact is very severe
requesting a waiver as the fix would be very complex and is not safe to integrate it for 6.9
As this issue become a P2 I should probably clarify some things mentioned in the comments above: 1) the fixes proposed in the comment#4 are only WORKAROUNDS which were ment as a temporary fixes until the main issue is fixed properly 2) the MAIN problem here is that JSP parser doesn't run within the parsing.api, it has its own infrastructure for running the parsing, getting the results by clients etc. 3) So the proper FIX is the migrate the JSP parser to the parsing.api so it is synchronized with the other parsers running on the JSP page. This would fix the synchronization problems described in comment#2. The fix is not trivial a can be potentialy dangerous, so I agree with waiving this issue.
Requesting a waiver as the fix would be very complex and is not safe to integrate it for 7.0.
Waiver for 7.0 is approved.
Requesting a waiver for 7.0.1.
Approved.
As written above, the fix requires migration of the JSP editor to the Parsing API infrastructure, which is a large and risky task that requires a lot of resources. We are currently not planning to do that, as this is the only known problem that is not fixable within the current codebase - all other bugs we came across can be fixed without a major rewrite. Given this fact, I am closing this bug as WONTFIX - if you feel strongly that it must be fixed, please reopen with justification.