Problem:
While executing a bean module using Spring, it throws up an Unicode 0xc invalid character exception.
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException:
Line ** in XML document from ServletContext resource [/WEB-INF/spring/mymodule.xml] is invalid; 
nested exception is org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0xc) was found in the value of attribute "value".
Caused by: 
org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0xc) was found in the value of attribute "value".
Background:
I was working on something in the office, which required me to write a simple bean using Spring DI (dependency injection). Not a big problem, and the code was complete in a day. I tested the code on my Windows machine and it worked fine. Perfect, I checked in the code, and was waiting for the build. After the build completion, I went ahead to test it on the QA machine. As soon as the module was executed, I got the mentioned error. Now this was something I wasn't expecting. The module executes perfectly fine in the DEV instance, then why this in QA.

As always I searched for the exception thrown in Google, and almost all results I found indicated that there was some invalid character. The character 0xc in Unicode is meant for form feed. I checked the XML encoding and it was indeed UTF-8. I validated the XML for Unicode escaping and it came out with flying colors. The XML validated against the DTD. I opened the XML in a Hex Editor, and I could find no instance of a form feed in the file.

Then what could have been the problem? Well, After a lot of struggle I realised that the line being pointed to referred to a property in the qa.properties file. I hard coded the value in mymodule.xml and it works fine.

Reason:
The problem arises from the fact that the property files when created using Eclipse are ISO-8859-1 encoded, whereas the XML files are UTF-8 encoded. Hence, when Spring replaces the definition property from the properties file, it expects the value in the same encoding. This causes Spring to detect an invalid character (Form feed 0xc in my case) This is particularly a problem of encoding and not of the invalid character.

Solution:
If you still haven't guessed it, make the property file adhere to the same encoding scheme as the Spring XML (UTF-8 in my case), or the crude way, hardcode the value in the XML file.

Hope this helps.

written by Sandeep Gupta

Tuesday, November 27, 2007 at 12:15 PM

IE6 Flicker Problem

with 1 comments

Yesterday, I was upgrading the Modified Foliage Theme for Blogger. I had been testing it out in Firefox 2.0 and IE 7.0 for long. This time it was IE 6.0 that I was testing the theme on. The theme almost behaved in the manner expected, except a few DIV issues. After fixing them, my attention diverted to a flicker that was caused in the pull button.

As soon as I hovered over the pull button, there was a flicker over the string drop animation. When I de-hovered, there was a flicker again. It was occurring again and again. The browsers are supposed to cache to all images, and hence, my first assumption was it to be just another CSS issue. I tried aligning the images using absolute position, then trying it with a table, but the flicker didn't go. The last option as usual is GOOGLE.

A quick search over the Google made me realize that the problem is inherent in IE 6.0 It's not an issue with the HTML code, but with the way IE6 handles background images defined in CSS.

The solutions to the problem are defined on this page and this page. The following is mostly a rewrite of what has been written elsewhere.

The problem:
  • A flicker is visible with background images defined in a CSS, when the explorer's cache settings are set to "Check for newer version with every visit to the page."
  • Is caused only in Internet Explorer 6.0, and not in previous or later versions.
  • There is no patch for IE 6.0 which rectifies this problem.
  • There is no client side fool-proof solution to it.
  • It can be resolved by server-side configuration, or by using Javascript (which again could be blocked by a user).
Solutions Available:
  • A solution using Apache Server is available here.
  • A solution using javascript is as under (source),
    try {
    document.execCommand("BackgroundImageCache", false, true);
    } catch(err) {
    }
    Just add the above javascript code to the page load event.
  • A solution for IIS server is explained here.
  • A solution for ASP.NET server is explained here.
Hope this helps.

written by Sandeep Gupta

Thursday, November 22, 2007 at 2:45 PM


We all have been expecting OpenSocial API release by Google, which was supposedly expected on Thursday. But, what a goof-up by Google. It has already featured projects on its Google Code Featured Blog mentioning the OpenSocial API usage, but the link is broken. Read the entries on the blog here.

The projects featured till now are Emote, Flixster, Songs iLike, Fan Site and My Music. Even the respective project sites contain no information of the mentioned examples.

Great Goof-up by Google.

Update: 2nd Nov 2007 2:15 PM

Google has just released 4 more projects viz. Rise of Atlantis, Visual Book Shelf, FotoFlexer Live, and Jimi Hendrix Gadget. Finally, the link for OpenSocial API is also live. Read more on OpenSocial API here.

written by Sandeep Gupta

Friday, November 2, 2007 at 2:15 PM

While cleaning up my Thunderbird today, I came across this issue which kept me (and my team) on toes for a few days. It is an old issue (almost an year now) which I pen down due to some fond memories. The problem is related to J2EE Web Application project. The project background is not needed to relate to the problem.

The application was using Struts 1.1 and was deployed in Weblogic 8.1 SP1. The problem occurred while I was deploying my WAR (in the exploded form) after modification of struts-config.xml, and not when I was deploying the complete WAR as a whole. I had used many struts validators and parsers, but none reported the error. The exception received was,
<Oct 10, 2006 3:51:04 PM GMT+05:30> <Error> <HTTP> <BEA-101216> <Servlet:"action" failed to preload on startup in Web application: "myApp".
javax.servlet.UnavailableException: Parsing error processing resource path
at org.apache.struts.action.ActionServlet.handleConfigException(ActionServlet.java:1035)
at org.apache.struts.action.ActionServlet.parseModuleConfigFile(ActionServlet.java:1014)
at org.apache.struts.action.ActionServlet.initModuleConfig(ActionServlet.java:955)
at org.apache.struts.action.ActionServlet.init(ActionServlet.java:470)
at javax.servlet.GenericServlet.init(GenericServlet.java:258)
at com.myapp.controller.servlet.MyFrontControllerServlet.init(MyFrontControllerServlet.java:91)
at weblogic.servlet.internal.ServletStubImpl$ServletInitAction.run(ServletStubImpl.java:1070)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
at weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubImpl.java:893)
at weblogic.servlet.internal.ServletStubImpl.createInstances(ServletStubImpl.java:842)
at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:782)
at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServletContext.java:3236)
at weblogic.servlet.internal.WebAppServletContext.preloadServlets(WebAppServletContext.java:3181)
at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:3154)
at weblogic.servlet.internal.WebAppServletContext.setStarted(WebAppServletContext.java:5637)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:866)
at weblogic.j2ee.J2EEApplicationContainer.start(J2EEApplicationContainer.java:2017)
at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:2058)
at weblogic.management.deploy.slave.SlaveDeployer$ComponentActivateTask.activateContainer(SlaveDeployer.java:2624)
at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.doCommit(SlaveDeployer.java:2547)
at weblogic.management.deploy.slave.SlaveDeployer$Task.commit(SlaveDeployer.java:2349)
at weblogic.management.deploy.slave.SlaveDeployer$Task.checkAutoCommit(SlaveDeployer.java:2431)
at weblogic.management.deploy.slave.SlaveDeployer$Task.prepare(SlaveDeployer.java:2343)
at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.prepare(SlaveDeployer.java:2511)
at weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(SlaveDeployer.java:833)
at weblogic.management.deploy.slave.SlaveDeployer.prepareDelta(SlaveDeployer.java:542)
at weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(SlaveDeployer.java:500)
at weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCallbackHandler.java:25)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
>
A lot of discussions over the validity of XML and it being well formed happened. A few interesting notes worth remembering were,
  • Maybe some kind of file-locking occurs? How do you make a deploy? Just
    copy war's content into app's directory? Maybe this is the case, weblogic keeps reference to old struts-config.xml or something like that.

    When deploying as a war file, weblogic just removes old directory,
    creates a new one and no file-locking occurs.
  • guessing that there is a problem with the XML parser.
    For example (warning: this is a shot in the dark) I had problems with Java 1.4.x because it uses the "crimson" parser, that is very buggy. Once I used the Xerces parser everything went fine...
The root cause of the problem was the case-sensitive declaration of the entries in a struts-config.xml file. There was a letter in the name of the folder misspelt in upper case. The compilation of class did not fail being a Windows machine, and the JDK compiler could not distinguish the mismatch in package name and the tree structure. But when JVM tried to load the class, it failed.

If the package name does not match the directory structure (in case) then the above error is thrown. I am still confused as to why Weblogic throws it as a parsing error?

You can follow the actual conversation on the struts-user mailing group, or its web interface here.

written by Sandeep Gupta

Thursday, November 1, 2007 at 10:00 AM