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.
The NB 5.x had a ui editor for sun-cmp-mappings.xml that showed red Xs in the places where contents was invalid. There was also an xml editor which did not show any inline validation. Finally, the verifier did a full scale validation of contents and reported errors. In NB 6, the ui editor is not there. The xml editor still has no inline validation. The verifier validation is still in place. Excerpts from a discussion with Peter about validation in the ui: >> Yes, there is no UI. However if there is a way to figure out that things are invalid (and there are a number of >> trivial and probably some not so trivial things that can be checked) we can use the editor hint functionality. I >> have the scratch work for doing this on the XML pane with things such as context root, etc, but it's been on ice for >> several months and is not complete. > True, but I see editor hint stuff as an enhancement since we didn't have it before. On the other hand, we did show it > in the ui which has disappeared. Do you think this is worth working on? My feeling is, it's too late for this > release. For any given single field, it should be pretty trivial. I do not intend to handle the scope of what we had before, but I think putting in a few choice fields would be of value, both as a proof of concept and because certain fields are error prone and cause deployment failures if they are not valid (and as you noted, we used to validate these in the old UI -- that we are not doing so now is a regression.) <validation example for jndi names snipped> For inline errors, we would probably do something different wrt/ the error message database that the old system used (e.g. 'getMessageDB().update...()). We also wouldn't want to be running validation on the entire XML tree every keystroke. I haven't thought about this problem yet. The old message db was extremely fast for indexing and display of messages and fields were only validated on change (or on initial display). To find other errors we supported, you can browse the implementations of the method "public boolean validateField(String fieldId)" in the configbean folder, prototyped in Base.java and implemented by all derived classes that did any validation on any of their fields. Many of the errors are somewhat esoteric (as are the fields they represent) but a few are for common errors (like the JNDI case above, though admittedly obsolete due to them being optional in JavaEE5). You might be right that it's simply too late in the schedule to consider something like this. I just haven't thought it through enough. ===================== Bottom line - bug or enhancement? Worth doing for this release? If so, how many checks?
This is definitely an enhancement, not a bug. Inline errors for the new sun xml/multiview editors didn't make the M10 cutoff (or even the extension).
this isn't likely to get attention. and probably shouldn't.
no bug should be assigned to issues. distributing the load.