Bye-bye, Postfix...

Times ago I've dumped Sendmail and replaced with a Postfix. Now, after a while, having a number of requirements that needs to be implemented with something more sophisticated, it is a time to replace Postfix for something better, easier and more flexible.

My choice is now Apache James (http://james.apache.org/).

Tests went fine, things works as expected. Configuration is dull easy, like for those, who see an email server for the first time in their life. Apache James looks pretty good inside (source code), is extensible, has nice plugins and great API to make your own, if you like (that's exactly what I really need). Some folks reports it handles about 3K messages per a minute. I think, that's impressive number, but I don't need such anyways. :-)

The greatest thing of all this story: this particular mail server is a 100% pure Java.

How to run background process in GWT

There is no such thing as "background process" in Google Web Toolkit client, because... it is a client part. So you can not do threads, can not do daemons, since it supposed to be cross-compiled to JavaScript and run in a browser pretty ugly way. However, you can repeatedly call the same function. In JavaScript it is timeout. But you want to avoid JSNI for this. Hence, do the following: use a com.google.gwt.user.client.Timer. If you want call it periodically each 5 seconds, you can do something like this:

private void updaterProcess() {
  Timer timer = new Timer() {
       @Override
       public void run() {
           // call stuff here
       }
  };

  timer.scheduleRepeating(5000);
}

Shift happens...

Google got pissed off:

"We have decided we are no longer willing to continue censoring our results on Google.cn, and so over the next few weeks we will be discussing with the Chinese government the basis on which we could operate an unfiltered search engine within the law, if at all. We recognize that this may well mean having to shut down Google.cn, and potentially our offices in China."

Complete story here: http://googleblog.blogspot.com/2010/01/new-approach-to-china.html

Well done, Google! Well done.

How things gets screwed up, when you're not thinking...

Short note how JNLP is screwed up in the GlassFish.

You like GlassFish, aren't ya? Now, consider, you want distribute your application over JNLP, as I did on my radio website. It is an MP3 player with an ability send SMS messages, so far. Note, the website is in Ukrainian language, but you can simply click on that whacky image somewhere in the middle of the article. :-)

Since it is Java Web Start, the way you put it to the GlassFish is using Enterprise Application, then create a client to it, and then put your stuff there, pack as an ".ear" and deploy. Sounds cool, right? Yes, sounds very-very cool. Note that since it is Java Web Start, you don't want to listen to your complaining users for like "WTF is this?!" etc., instead you want your application:

• Be damn fast.
• Be damn small.
• Be damn quick.

However, not with Enterprise Application. Once you've packed your app as ".ear", it will suck up a sh*tload of useless jar's, verify each by unpacking, checking etc. On an average user's Vista laptop, where all the resources went to antivirus and antimalware package, you do not want it happen ever. Some of my users complained they had to wait 8 (eight, EIGHT) minutes to load a very little tiny application, like that one. Take a look what you've got in your cache among other crap: Java EE jar! Application Server runtime! OMG!..

Now... The obvious question is how to cure all this mess to make your 200K application start literally in a moment? Forget stupid Enterprise Application, once you go with JNLP. It is still good if you do EJB things (I do, so far so good). Never touch JEE for client part (make sure it is server thing in your app) and deploy as a simple GUI that talks to your server via webservices (REST or SOAP is fine). Deploy it just manually, as a static data somewhere on the server.

How deploy it manually on GlassFish. I assume you're using NetBeans? If no, you should. :-) So go to the properties of your Project, select "Web Start enabled", sign your jars with an SSL certificate and rebuild all the stuff. In your Project's "dist" folder you will find ready to go app (almost). Then edit codebase URL in order it point to your website over HTTP instead using file:// from local system. Tar/gzip all the dist/ folder with everything inside, scp to your server and unpack to the static folder of the GlassFish ($ROOT/domains/$DOMAIN/docroot) or, if it is GlassFish + Liferay, then look inside deployed Liferay package.

That's it.

P.S. Sun, I hope Oracle will kick your ass very hard to gently encourage you think properly and organize your technology the way it be once actually usable for everyone.