Handling CDATA in JAXB without escaping

JAXB by default escapes characters inside a string in the Java model when it converts the Java model to XML. This creates issues if you have CDATA present in the string. You will have even the CDATA tags escaped [i.e <![CDATA[&lt ], which makes it difficult for the consumer of the final XML for processing. So, to avoid this and to handle CDATA in JAXB the way you want, there are 3 approaches :

1. Using XMLSerializer and OutputFormat :  Usage of this can be found in here. In the OutputFormat, one can specify the elements to be treated as CDATA. But both these classes XMLSerializer and OutputFormat - have been deprecated since Xerces 2.9.0. Latest Xerces version is 2.11.0. Following is what the Xerces documentation says : This class was deprecated in Xerces 2.9.0. It is recommended that new applications use the DOM Level 3 LSSerializer or JAXP's Transformation API for XML (TrAX) for serializing XML. See the Xerces documentation for more information. Ref https://xerces.apache.org/xerces2-j/javadocs/other/org/apache/xml/serialize/XMLSerializer.html https://xerces.apache.org/xerces2-j/javadocs/other/org/apache/xml/serialize/OutputFormat.html
2. Using XMLAdapter and Character Escape Handler :  In this approach, one needs to 
1. Specify Adapter class in the bindings.xjb for String element to be handled as CDATA. You can find how to specify it here. In the adapter class, in the marshall method one needs to add CDATA tag to the argument string.
2. During marshalling of the javamodel by JAXB, one needs to specify CharacterEscapeHandler which can handle CDATA element without escaping. You can find usage here. Any other special handling like escaping in certain cases, also need to be handled. This is a nightmare to maintain.
3. Using JAVAX XML Transformer APIs :  You can find the usage of this approach here. In this case, Javamodel from JAXB would be marshalled into a DOM document(w3 doc). Then, it would be transformed into XML string the way we want by JAVAX Transformer. In the Transformer, we can specify the list of elements to be handled as CDATA.

I would recommend using the third approach since it is configurable, easy to maintain and part of standard Java package. 

Solution for web pages with white spaces failing in Internet Explorer 9 (IE9)

If you have a webpage with white spaces/new line character between the ending of one html tag and beginning of another, then chances are there that it may not display or work properly in Internet Explorer 9. I checked the  html code generated for Internet Explorer 8(where it works!) and Internet Explorer 9. There is no difference. Then what has gone wrong?

Issue : 

• Internet Explorer 9 is conforming to HTML 5 specifications. Accordingly HTML parsing has been changed in IE 9. One change that affects almost every page is how whitespace parsed. While IE8 removes or collapses whitespace, IE9 persists all whitespace into the DOM at parse-time. Refer to the following link for more details : http://blogs.msdn.com/b/ie/archive/2010/09/13/interoperable-html-parsing-in-ie9.aspx 

• So, if you have java script code which accesses the nodes in DOM ignoring the white spaces previously, then you are bound to be in big  trouble. In IE9, all the white spaces/new lines in DOM are treated as nodes. So, when you traverse using APIs like firstChild may not reference to the element you might have intended.

Solutions :

1. If you want to traverse elements (ignoring the white spaces) only then use Element Traversal APIs - calling functions such as nextElementSibling to ensure that you don’t reference a stray newline character or white space by mistake.
2. On the other hand, make sure that your code is backward compatible with previous browser versions by adding check for the same while traversing the elements in DOM
3. Removing the white spaces - this is a tedious job, as you would be doing the work of the browser done previously. But here you don't need to have the check for Internet Explorer browser versions. 

How to avoid GetSaveFileNameW failing in IE9 in Windows7?

GetSaveFileNameW is a Windows API. It creates a Save dialog box that lets the user specify the drive, directory, and name of a file to save. I had a ActiveX  plugin which was using this function to get the name of the file user is saving. It was working fine in IE8 in Windows XP but it started failing in IE9 on Windows 7. It did not create a dialog box and returned error!

CommDlgExtendedError : When inquired through CommDlgExtendedError about the reason for failure of GetSaveFileNameW, it said error code : 0xFFFF

Explanation for error code 0xFFFF(CDERR_DIALOGFAILURE) - The dialog box could not be created. The common dialog box function's call to the DialogBox function failed. For example, this error occurs if the common dialog box call specifies an invalid window handle.

Debugging : Internet literature provided little help. Then, I checked whether this function - GetSaveFileNameW - worked fine for a standalone application. It did and then tried with the same set of parameters in ActiveX plugin. But it did not work for ActiveX plugin 

Reason for failure : Later I found that IE9 was not fully supporting the ATL version I was using. GetSaveFileNameW was failing because of the flag OFN_EXPLORER. How?

Solution : OPENFILENAMEW structure is filled before passing as a parameter to GetSaveFileNameW. Here, we set the flag OFN_EXPLORER in the Flags attribute of OPENFILENAMEW structure. If the OFN_EXPLORER flag is set, the system uses the specified template to create a dialog box that is a child of the default Explorer-style dialog box. If the OFN_EXPLORER flag is not set, the system uses the template to create an old-style dialog box that replaces the default dialog box. I was setting the flag - OFN_EXPLORER. I now reset the OPENFILENAMEW and it works!!!

Workaround for old Firefox Plugins crashing on Windows 7

I had an old plugin which was working fine in Windows XP. When I moved to Windows 7, this plugin kept crashing whenever opened. After a while, I was able to find a workaround for making this plugin work.

The answer lies in DEP (Data Execution Prevention). This feature was enabled in my Windows 7 machine. After I disable this feature I was able to run my plugin in Firefox. Here is how you can disable DEP in Windows 7.

1. Go to command prompt
2. Execute the command bcdedit /set nx AlwaysOff
3. Reboot the machine (rebooting is required for the above setting to reflect)

Ideally with DEP enabled, if you want to run your plugin, you have to build the plugin with the latest version of Windows SDK.