DWR version 1.1.RC1 is now available for download.

The new features include:

• New Converters for Enums and Objects
• The ability to keep Bean properties hidden from Javascript
• Integration with Struts, JSF, Beehive
• Improved integration with Spring, Hibernate and various scripting languages
• Support for synchronous calling
• Improved error handling
• Better support for timeouts and call hooks
• Many updates to the DHTML library (DWRUtil) to allow more ways mutate your web pages with data from the server

DWR is a Java open source library which helps developers wanting to write web sites that include AJAX technology. It allows code in a web browser to use Java functions running on a web server as if it was in the browser.

Technorati tags: dwr, ajax

Responses[3]

Posted by Joe Walker on 20 February 2006 10:54:05 GMT #

• Fred: Could you tell me where on the LAN the docs for Project X are?
• Shiela: Oh, they’re not on the LAN, I found them on the Internet.
• Fred: Much better – I’ll Google for them.

There is something very wrong when I can do a free text search over 20 billion pages stored on 80 million geographically distributed servers in “0.60 seconds”, but trying to find the same text in a few thousand docs stored on 1 Windows server takes 20 minutes and then gets the wrong answer.

Yeah – apples and oranges, and the title is flamebait, but there is something wrong when I’ve got more chance of finding a doc somewhere on the Internet than on the file server in the room next door.

What good, simple solutions are there to the local search problem in the corporate environment?

P.S. If you are thinking of suggesting Google Desktop as a corporate search solution then you deserve a turbo wedgie for not considering what it will do to the network and servers when all those clients want to update their indexes.

Responses[6]

Posted by Joe Walker on 16 February 2006 22:52:58 GMT #

This sequence of events ends up with the release of IE7 being a bit of a train wreck for many users. I'm not totally sure about the logic behind this sequence of events. What do you think?

First the facts:

• The renderers in IE5.5 and IE6 are broadly similar, some CSS bugs fixed, but nothing compared to the IE7 changes.
• Very few people use IE5 any more.
• Many web developers have got lazy and are in the habit of just testing with IE6 and ignoring IE5.5.
• For the more conscientious, there is a trick to allow IE6 and IE5.5 to run on the same PC.
• The .local trick doesn't appear to be working with IE7.
• Web developers with bad habits from the IE6 world and those that don't have VMWare (less excuse now!), are likely just test with IE7 and ignore IE6.
• IE7 breaks CSS hacks and makes big changes to the way the renderer works, so IE6 and IE7 have very different rendering engines.
• New web pages that have only been tested in IE7 will probably look very bad in IE6, and there could well be a lot of them.
• The uptake of IE7 will be fast for people with XP (Windows update) and slow for everyone else.

Net result: IE6 users get a web experience that gets worse over time. They blame IE and move to Firefox.

I think it would be wise for Microsoft to admit to the .local trick and make it work properly. We need a way to run multiple copies of IE without running multiple OSs.

I don't buy the "but IE is part of the OS" argument. Whatever the technicalities are - we need a way to run IE6 and IE7 side-by-side, and there are some pointers as to how to do it. Lets make it work properly.

Personally I think it's likely that IE7 will severely curtail the market-share haemorrhaging that IE is now suffering, and the browsers will sit about 85/15 or whatever for quite a while.

But anything above 10% is good enough for me. Double figures means that most websites won't be able to ignore Firefox and will be forced into the standards compliance route, and so long as we get that, the battle to force everyone down the proprietory route is for Microsoft.

Responses[1]

Posted by Joe Walker on 07 February 2006 08:42:43 GMT #

I've updated Venkman, the Javascript debugger for Firefox. The changes include:

• Now works on Firefox 1.5.0.1
• Fixed the multiple load bug - previously if you started Venkman, and then closed it, you couldn't get it back until you re-started Firefox.
• A start to getting it to work under Thunderbird and Flock

Get it here.

Technorati tags: javascript, debugging, venkman, firefox

Responses[4]

Posted by Joe Walker on 02 February 2006 08:29:37 GMT #

It appears that there is *yet another* change coming to the recommended way to connect Tomcat to Apache. I've tried mod_proxy, mod_webapp, mod_jk and mod_jk2 - well it appears that the new direction is mod_proxy_ajp.

mod_proxy allows Apache to proxy requests to other systems. Before Apache 2.2 it would only work with FTP and HTTP, but now it handles AJP too.

So before Apache 2.2 you could rule out mod_webapp (easy to configure, but obsolete) and mod_jk2 (unsupported and fallen behind mod_jk v1!) and your choice was mod_proxy (easy to get working but easy to create a security hole) or mod_jk (harder to configure but generally better).

If you can avoid the security hazards, it looks like mod_proxy_ajp may soon be a better option from Apache 2.2 and on. Either that or it’s just going to be another way to confuse everyone.

The next change I expect is that someone equipped with GCJ is going to come up with mod_tomcat - just compile the whole thing as an Apache module and forget all this connector nonsense!

Does anyone have experience of how mod_proxy_ajp performs?

Update: For more information on picking a connector you might want to consider:

• The Tomcat FAQ
• Confluence notes on the same

Responses[11]

Posted by Joe Walker on 01 February 2006 08:18:35 GMT #