Monday, July 17, 2006

hacking XMLDecoder for unsigned and network friendly applets

Want to avoid that at applet startup?

network: Connecting http://yourHost.com/META-INF/services/javax.xml.parsers.SAXParserFactory with proxy=DIRECT
network: Connecting http://yourHost.com//META-INF/services/javax.xml.parsers.SAXParserFactory
network: Connecting http://yourHost.com/META-INF/services/com.sun.org.apache.xerces.internal.xni.parser.XMLParserConfiguration with proxy=DIRECT
network: Connecting http://yourHost.com//META-INF/services/com.sun.org.apache.xerces.internal.xni.parser.XMLParserConfiguration

When used in an usigned applet (yes there are complex hacks if you are willing to pay for a certificate), XMLDecoder also use to open unecessary sockets to lookup the applet code base on the server. The trouble isn't so important as only something like 4 sockets will be opened. But depending on your server load, this can easily result in a 1 second latence when opening the applet. Indeed, it appears that code base lookup when loading classes is a process that completely prevent others threads from running, be it in a simple other Thread or even in the SwingWorker thread.

Also, since this latence occurs at the applet startup is your applet is to open a server side XML file, then the latence is finally really annoying and make applets look sluggish compared fast and responsive ajax applications.

Fortunately, I found a way to avoid those 4 sockets. Instead of using XMLDecoder, use the following derivative:

(Also, to decode encode side XML files in an applet using an usigned applet, we use AppletFriendlyXmlEncoder, an applet friendly derivative of XMLEncoder. )

The full source of AppletFriendlyDecoder which extends XMLDecoder is to be found on the Visualmodeller wiki here:
http://www.visualmodeller.org/wiki.fcgi/AppletFriendlyXmlDecoder

A demo of it can be found in JGraphpad Community Edition demowed online at Visualmodeller here:
http://www.visualmodeller.org