Fixed minor related problems 

http://j2ee.netbeans.org/source/browse/j2ee/ddapi/src/org/netbeans/modules/j2ee/dd/impl/common/DDUtils.java?r1=1.6&r2=1.7
http://j2ee.netbeans.org/source/browse/j2ee/ddloaders/src/org/netbeans/modules/j2ee/ddloaders/web/DDDataObject.java?r1=1.10&r2=1.11

Created attachment 25069 [details]
Stack trace

I think it should be fixed in 
org.netbeans.modules.xml.text.syntax.UniKit.write(OutputStream, Document, int, int)

There isn't any problem with the UniKit.write(...). It is correct that the
method throws UnsupportedEncodingException. The calling code has to catch it and
handle properly (like save cookie of XMLDataObject does as Martin mentioned).
For more info how to handle it see  

org.netbeans.modules.xml.core.text.TextEditorSupport.saveDocument() from
xml/text-edit module.

Fixed 

http://xml.netbeans.org/source/browse/xml/multiview/src/org/netbeans/modules/xml/multiview/EncodingHelper.java?rev=1.1&content-type=text/vnd.viewcvs-markup
http://xml.netbeans.org/source/browse/xml/multiview/src/org/netbeans/modules/xml/multiview/Bundle.properties?r1=1.12&r2=1.13
http://xml.netbeans.org/source/browse/xml/multiview/src/org/netbeans/modules/xml/multiview/Utils.java?r1=1.16&r2=1.17
http://xml.netbeans.org/source/browse/xml/multiview/src/org/netbeans/modules/xml/multiview/XmlMultiViewEditorSupport.java?r1=1.51&r2=1.52
http://j2ee.netbeans.org/source/browse/j2ee/ddapi/nbproject/project.xml?r1=1.5&r2=1.6
http://j2ee.netbeans.org/source/browse/j2ee/ddapi/src/org/netbeans/modules/j2ee/dd/impl/common/DDProviderDataObject.java?r1=1.3&r2=1.4
http://j2ee.netbeans.org/source/browse/j2ee/ddapi/src/org/netbeans/modules/j2ee/dd/impl/common/DDUtils.java?r1=1.7&r2=1.8
http://j2ee.netbeans.org/source/browse/j2ee/ddloaders/src/org/netbeans/modules/j2ee/ddloaders/multiview/DDMultiViewDataObject.java?r1=1.8&r2=1.9
http://j2ee.netbeans.org/source/browse/j2ee/ddloaders/src/org/netbeans/modules/j2ee/ddloaders/multiview/EjbJarMultiViewDataObject.java?r1=1.52&r2=1.53
http://j2ee.netbeans.org/source/browse/j2ee/ddloaders/src/org/netbeans/modules/j2ee/ddloaders/web/DDDataObject.java?r1=1.11&r2=1.13

http://j2ee.netbeans.org/source/browse/j2ee/ddapi/src/org/netbeans/modules/j2ee/dd/api/ejb/DDProvider.java?r1=1.7&r2=1.8
http://xml.netbeans.org/source/browse/xml/multiview/src/org/netbeans/modules/xml/multiview/XmlMultiViewDataObject.java?r1=1.53&r2=1.54

The fix involves only ejb-jar.xml and web.xml

This comment applies to the SJSAS configuration files (sun-web.xml, etc.) though
it also seems to apply to any XML file (I reproduced it w/ wscompile config
files as well.)

Suppose you have a web project w/ sun-web.xml that has invalid encoding and you
open the project.  "java.io.UnsupportedEncodingException: UTF-999" (full trace
attached below) is thrown when the mimetype is being sniffed.

It seems to me that this should be handled by the mime resolver code.

Created attachment 25995 [details]
Stack trace when sniffing mime type on an XML file w/ invalid encoding.

Yes, this looks like something deep in the openide/core code. Reassigning to
openide/filesystems.

While resolving mimetype org.netbeans.core.filesystems.DefaultParser.parse 
behaves exactly the same way as if there was whatever other parsing problem -
which means: catches this UnsupportedEncodingException, calls EM.notify with
severity INFORMATIONAL and return null. Finally text/xml is returned anyway
because in FileUtil is still this mimetype hardcoded for extension .xml. 

Is there anything wrong on this behaviour ? If so, please reassign back to me. 

Reassigned back to serverplugins.

So what is the remaining issue? I believe the only remaining area is
sun-web.xml, reassigning to Peter.

I did small check with this results:

web.xml, ejb-jar.xml - the warning message is displayed "The declared encoding
XXX is not uspported, Changed it to UTF-8?" If you user push button NO, new
message is displayed: "The declared encoding XXXX is not supported. The data
will be treated as UTF-8. After this the file is saved in UTF-8.

faces-config.xml - still Missing resource exception

sun-app.xml, sun-ejb-jar.xml - still UnsupportedEncodingException and in the
same time the question File xxxx was modified externally. Reload it?

jsp document - There is message: "The XXXX character set that is used in
yyyy.jspx is not a valid character set for JSP pages. Do you want to save the
file using the UTF-8 character set?". The file is saved in utf-8 encoding and
nothing is changed in the file. When you open this file, then the ide ask user
"The XXXX character set that is used in yyyy.jspx is not a valid character set
for JSP pages. Do you want to load the file using the UTF-8 character set?"

Struts config.xml, *.tld, *.xml files which are handled only with the xml data
loader - display question "The declared encoding XXX is not supported, Changed
it to UTF-8?" If choose no, then the file is not saved, if choose yes, then file
is saved in utf-8,  the old prolog is commented out (<!-- was: <?xml
version="1.0" encoding="XXXXX"?> -->) and the new prolog with utf-8 encoding is
inserted into the file.

At first we need to solve the exceptions during saving faces-config.xml and
sun-*.xml. I'm going to fix the issue for faces-config.xml, which I fired as
separate issue #68300.

Peter, should you fix the exceptions during saving sun-*.xml files?

In the future, we should try to have same behavior, as Martin wrote, for all
.xml files in these cases. But I am not sure, that we are able to do it in the
NB 5.0 timeframe.

I am working on the exceptions when saving sun-xxx files from XML text right
now, will have a fix soon.  I somehow missed seeing these when I had this bug
earlier or I would have already fixed them :(

I checked a fix that resolves the problem when saving a file w/ invalid encoding
that was open in the XML text editor for the sun-xxx files.

http://serverplugins.netbeans.org/source/browse/serverplugins/sun/sunddui/src/org/netbeans/modules/j2ee/sun/share/config/ConfigDataObject.java?r1=1.10&r2=1.11

Here's another incarnation of this bug:

Create a web app w/ sjsas as the target server.  Open sun-web.xml as text to
confirm UTF8 encoding (and existence of this file), then close it.

Now in an external editor, open this sun-web.xml and change the encoding to
UTF-999 (anything illegal), then save.

Go back to the ide and select the sun-web.xml node with the mouse.  At this
point, I get an invocation target exception with the following attached massive
stack trace (includes some of the INFORMATIONAL exceptions commented on above,
but the problem seems to be a NPE in XmlDataObject.InfoParser.waitFinished().)

I see no evidence that the SJSAS plugin is involved here, or can catch any of
these.  I can dig into XmlDataObject to see if indeed this is our fault, or
perhaps someone who knows this area better can either tell me it's not, or point
me in the right direction.

Created attachment 26730 [details]
NPE in XmlDataObject$InfoParser.waitFinished

So what's next?

Petr Pisl promised to look at this.

The problem with NPE which was mentioned by PCW, is not in the xml module but in
the open ide/loaders, where they try to parse xml files. It happens for every
xml files and only if user modified the file externally. So I close this issue
and fire new one against open ide - loaders #69876

Verified in #200605160200 build.