Bug 114825

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?