Friday, December 22, 2006

Ubuntu trouble: uninitialized constant Mongrel::HttpHandler (NameError)


Ok so Rails is the must have framework, and Mongrel the must have server. But may be you just had an error when trying to launch Mongrel on Debian and you are googling desperately for a solution.

So, if after typing:

you get:
uninitialized constant Mongrel::HttpHandler (NameError)

The reason on Debian might be your Gem package is outdated, so try to type:
sudo gem update --system

For me this upgraded Gem from 0.8 to 0.9, than I reinstalled Mongrel with:
sudo gem install mongrel --include-dependencies
sudo gem install mongrel_cluster --include-dependencie

and voilà, Mongrel is now working!

Hope this help.

PS: Viva Lula! viva Chavez! fudeu a direita! Com mas de 60% dos votos contra direita, foi uma boa goleada contra burguesia, valeu. (translation: no putsh in Brazil neither Venezuela, South America is going fine).

Tuesday, September 26, 2006


I'll try here to inform people that may not know the situation one week before the presidential elections in Brazil. After having been evinced from the power in 2002, those who always ruled Brazil since its colonisation are trying everything to prevent Lula from being elected again.

Opinions pools were pretty clear since several months ago: Lula was summing about 55% of the vote intentions against less than 30% for the right wing candidate. But the oligarchy -still very powerful in Brazil- tried to biased the public opinion. Journals such as Veja are lying more than Bush, while others like the "Folha de Sao Paulo" are obviously biasing the facts against Lula. The problem is that there aren't yet any mass media to balance those partial views from journals owned by the oligarchy.

Among the most scandalous stuff, are: the national lawyers association (OAB) is trying to impeach Lula; while the government was top blame, because they bought vote from opposition politicians to gain governability, the biggest problem is that the press only persecuted the government without even persecuting those corrupted politicians from the opposition who used to be corrupted for decades. Finally one week ago, a tape proving the corruption of Jose Serra -a former rival of Lula- has been discovered. Instead of investigating this case, the press is only focused on linking Lula with irregularities when obtaining that tape, again, they are trying to impeach Lula despite the total lack of proof and its huge popularity. They are thus trying to shunt the democratic process in Brazil because they fear to loose their privileges inherited from the colonnial situation.

Lula is very popular in Brazil, it's the first president who helped the poorest of the poor of Brazil. He is hopefully going to be elected any way. But still, the putsch attempt should be denounced anyway. It's our duty to blame the PSDB party and the mass media they manipulate wherever they go (that's why I'm telling it in english).

The issue is nothing funny. While the brazilian mass media (mainly Globo) are hiding the facts, they are more people killed in 3 months in Sao Paulo than during the whole second war in Lebanon! Corrupted politicians such as Jose Serra (PSDB) are widely responsible for letting that violence run out of control!

I'm only giving my view here. Others may defend the cause better (PT web site, , blogdareeleicao) , and the good results of Lula and popularity can be verified against numbers from impartial organisms. Here are such indicators:
details of numbers
popularity pool

Friday, September 22, 2006

Sun accepted the annoying BeanInfo lookup in XMLEncoder as a bug, vote for it!


As I described it here, XMLEncoder is giving too much pain when marshalling javabeans in unsigned applets. I've built up a workaround framework, but still, a few BeanInfo meta classes gets looked up on the server (while they don't even exist, so it's only freezing the network and loading the server). Also I can't tell if my framework really scale to any application and if there is no side effect. If there are they would be hard to debug in such a marshalling context.

We should just be able to disable that codebase lookup. Lots of problems with applets indeed come from the code base lookup, among them: problem with ResourceBundle, Services lookup, XMLEncoder, XMLDecoder (less annoying as the workarround is fully efficient). So I reported that to Sun Microsystems and the bug has been accepted. Here is the link.

So if you find it annoying and want a fast and easy marshalling in applets, if you want a faster and smaller JGraphpad CE, please vote for that bug here:
(you should create an account if you don't have one).


Thursday, September 21, 2006

Applet revival: JGraphpad CE BLACKJAX applet size cut from 450K down to 110K thanks to Pack200!

Pack200 is an underestimated widely deployed java tool to speed up dramatically the download time of applets or webstart applications.

I was already aware of an other 'BLACKJAX' like applet deploying Apache Derby on the client. Then I heard its creator claimed he cut Derby from 2Mb down to 600kb using Pack200..

So Pack200 is a class compressing/deflating tool deployed along with the JRE since version 1.5 (Tiger). How it works: in short applets and webstart apps are still requesting a jar archive on the server. But on the server side, you catch the fact the a different encoding (pack200-gzip) is requested by java 1.5+ clients. When requested, you'll then return the "packed" jar version, else (JRE prior to 1.5) you'll return the normal jar archive. JRE 1.5+ webstart and applet clients will deflate the packed archive on the fly saving a huge amount of server load and bandwidth.

Of course, this transfer win is only worth the CPU overhead on the client side if your archive was large enough. Make your benchmark.

Results are here:
So what about JGraphpad Community Edition? Without plugins (but with JGraph) - that's configured as the minimal online diagram editor - JGraphpad CE is weighting about 450K. Pack200 cut down the archive to 110K which is a very big win! Frankly I didn't benchmarked the extra overhead against the transfer win, but overall the win is HUGE! Overall, the applet startups 3 times faster!

So, yes it means that JGraphpad CE which is by far a more complex app than TinyMCE or FCKEditor which are 'only' online word processors, is still something 2 times smaller to download!!! (And with our "Javascript sugar", it starts up just as fast). Really amazing.

Now consider that JGraphpad CE is architectured so that you can download some plugins in the background (until you really need them) while diagramming with the core JGraph application, it turns JGraphpad CE really credible for diagram online edition.

Limits: JGraphpad CE require java 1.4.2 at least to run. But with java 1.4.2 you'll have to download the classic jar (it's totally transparent however). Only happy java 1.5 and 1.6 users will get their first download time boosted thanks to the Pack200 compression.

Server Side details:

JGraphpad CE has been designed to be server side agnostic. It only two use standard GET and POST HTTP methods to download/upload a diagram from the server. So you can use what you want to handle your uploads. I personally use Python within the MoinMoin wiki (normal file upload feature), but you could use Java, PHP or Ruby, no problem.

Still getting the Pack200 trick properly configured is server side dependent. It's easy to find out how to do with a Java server.

For an Apache server, the trick is really easy, it's explained in that excellent article.

Finally, if you can't o don't want to bother with Pack200, just put the jar in the root of the applet codebase directory as usual and this will work.

I'll soon provide a bunch of official documentation about that new JGraphpad CE release. Don't hesitate to send your feedback.

Friday, September 15, 2006

AJAX + Applet = ? ... => BLACKJAX !

OK, apparently I'm not alone thinking Ajax apps and applets can interact together to provide richer Internet applications, see this other blog also. Indeed:
  • Ajax is better for fast responsive GUI and document centric applications.
  • Applets on the other side provide better graphics, DB connectivity, XML processing or any heavy and maintainable business logic.
Okay, but now we need to name this new way of bridging those technologies. I propose to coin:
"BLACKJAX" standing for:
Background Liveconnect Applet Code Kicking Javascript and XML.

That's indeed a mix between AJAX and Applet. 'Asynchronous' is better replaced by 'background' which means the same thing but makes a funnier acronyme.

A new tech is born, let's hype arround it!
I'm waiting for your comments. Cheers,


Tuesday, August 15, 2006

degraded AJAX app + pre-loaded hidden java swing applet, the best deployment option for complex rich clients?

1) When AJAX isn't enough to address complex visualization or complex UI (or: there is no Java2D in javascript)

The trend is definitely to port traditional desktop applications to the web using AJAX. To overcome browser incompatibilities and javascript language flaws, we are using lots of frameworks including the Google Web Toolkit for instance. Those are fine but will only work well within a limited range of use cases as I will explain.

There is a use case indeed where AJAX+frameworks aren't enough: the case where you need superior visualization features like diagram editing or diagram driven modelling for instance (think about the equivalent of the Visio desktop app to model UML online for instance).

Ultimately, the point is that javascript in browsers doesn't allow you to dynamically draw a bunch of lines without consuming too much memory. Yes there are some attempts out there:
but as you can see by yourself, those trick doesn't scale to dozens of animated lines, no way.

2) SVG applications fall into the same deployment trap as java: not everybody has got the required runtime platform

Then what? Oh yes, there are those guys that will tell you to use SVG. SVG is great indeed, but you know what, MS Internet explorer requires an external plugin (Adobe) to display SVG, so basically, your shiny SVG/AJAX app falls into exactly the same deployment trap than java: not everybody can run it because not everybody already has got the required runtime platform.

3) SVG+VML turns into a maintenance nightmare

Then what? There are those who will tell you: OK let's writte an AJAX app the will use SVG on Moz browsers and VML on Internet Explorer. Fisrt of all, unlike SVG, VML is an end of life product that's not that much powerful. And moreover, your AJAX/SVG/VML app has already turned one of those maintenance nightmares!

4) Then a java client is the best, even in 2006. But which one, webstart or applet?

So taking all this into account, the best target runtime for large deployment of complex visualization application is... JAVA. A good old one jre 1.4.2+ is already well deployed indeed and programming java is easy and best of all, java is a language able to handle the complexity.

Java? OK, but do you mean applets or webstart? Well actually I mean applets. While webstart is younger and got a better security sandbox, webstart won't allow you to integrate you application in the browser just like applets. And using all the DHTML browser facilities is very handy, especially in document centric applications like CMS or publishing tools.

Yes but aren't applet slow at startup? Well, yes they are. And you know what, that's almost normal considering all you can do with the java runtime (much more than Flash for instance). Also don't forget that applets are cached after the first use, so even if your huge applet first takes time to download just like any other web app, then only startup time matters.

5) Don't even wait for the applet startup, instantly popup a degraded AJAX app to handle the first user interactions!

OK, Javascript apps start a way faster than applets. So why not instantly popup a simple degarded javascript app to deal with the first user interactions while the heavy business logic is being loaded in a powerful hidden applet? After the applet is loaded, we swap the two and the user now plays in a full featured desktop Swing application...

6) Hidden Applet and degraded AJAX howto

I've read that some people advice to set the applet size to 1*1 pixel to hide it and then makes it larger to display it. However, unfortunately, it seems that this hack makes the resize quite slow in Firefox, giving the feeling that the app is unresponsive.

I've found a better way, style your Ajax Div container and Applet div container this way (using CSS) :
div.visibleAjaxDiv {height: none; overflow:hidden}
div.hiddenAjaxDiv {height: 1px; overflow:hidden}
div.visibleAppletDiv {height: none; overflow:hidden; visibility:visible}
div.hiddenAppletDiv {height:1px; overflow:hidden; visibility:hidden}

then switch the Ajax and Applet div class when appropriate (for instance when the user request a complex interaction in your Ajax app, after you checked that the applet has been fully loaded indeed).

7) Liveconnect as the glue between the AJAX app and the applet

What you want is that the applet will remember what the user first told you in the AJAX app (for instance the name of the diagram to be created) and you also want the AJAX app to remember what the applet told (for instance you hide again the applet after editing your diagram, but then you want the AJAX app to display the picture of the diagram when it has been uploaded...

8) Your applet needs to communicate with the server. XMLEncoder and XMLDecoder are a free lightweight persistence framework for your applet, but it requires some tuning to be used in an unsigned applet.

Hardcoding business object encoders and decoders is the best way to write unmaintainable and unnecessary code. Fortunately, java allows you to persist and read javabeans at no cost.

However, the DefaultPersistenceDelegate and Metadata java code suffer some flaws making them hard to use inside an unsigned applet (security exceptions and heavy network use), but fortunately, I found a workaround for both XMLEncoder and XMLDecoder, see those posts:

9) Conclusion

Yes this way of associating technologies seems a bit tricky and too novel for production use. However, I think this is the best available technology for complex visualization rich clients. Also, I don't consider it's more hacking than traditional AJAX frameworks. No it's not, most of this technology is traditional java programming, one CSS style sheet, two java classes to reuse and only a bit of javascript but less than a full blown AJAX app. Also, if several people start to deploy this way, we could build a framework and spread best practices. I think this is better than waiting forever that a better client runtime is widely deployed... All this is available now. Any comments will be very much appreciated.

10) An example?

Yes, I've got an example. Unfortunately, the degraded AJAX app is reduced to its simpler: only a clickable image launching the app, with a tooltip, image reloading and file save checking, but the Swing app is shiny and based on JGraph (the GPL version of JGraphpad). And it's not hard to follow that proof of concept and build a larger app following those guidelines.
see the example here: visualmodeller

Monday, July 17, 2006

hacking XMLDecoder for unsigned and network friendly applets

Want to avoid that at applet startup?

network: Connecting with proxy=DIRECT
network: Connecting
network: Connecting with proxy=DIRECT
network: Connecting

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:

A demo of it can be found in JGraphpad Community Edition demowed online at Visualmodeller here:

Thursday, June 15, 2006

hacking XMLEncoder for unsigned and network friendly applets

XMLEncoder is very handy to serialize javabeans without the burden of hard coding encoders and decoders. Unfortunately, the current Sun implementation doesn't work properly with unsigned applet (there are hacks if you are willing to pay for an applet certificate).

Especially using XMLEncoder in an unsigned applet is very likely to result in security exceptions and will run slow and without any background threading solution.

Indeed, the DefaultPersistenceDelegate used by XMLEncoder for common javabeans uses to kill the network by opening dozens of sockets because it looks up for beanInfo classes on the server code base for every type inside your bean.

Fortunately, I worked hard and dicovered a hack: use the following encoder instead of XMLEncoder (you may adapt it a bit to your own beans in order to avoid some more specific beanInfo lookups). It's currently used in the last JGraphpad Community Edition online diagram editor.

Also, to decode server side XML files in an applet using an usigned applet, we use AppletFriendlyXmlDecoder, an applet friendly derivative of XMLDecoder.

The full source of AppletFriendlyEncoder which extends XMLEncoder is to be found on the Visualmodeller wiki here:

A demo of it can be found in JGraphpad Community Edition demowed online at Visualmodeller here: