Release Candidate 1 of Helma 1.6.3

The
Helma 1.6.3rc1 release candidate
contains numerous bug fixes and many minor improvements, such as support for secure HttpOnly session cookies, logging improvements, several changes to the way file paths to different resources are resolved, and Helma is now again backwards compatible with Java 1.4, to mention just a few.

Introduced hopdir servlet parameter to be able to set the helma directory.

The location of db.properties is now customizable using the dbPropFile server property, fixing bug 640

Fixed bug with closed database connections in very long running requests by making sure connections are re-checked every 10 seconds.

Changed HopObject.getOrderedView() to return a transient HopObject instead of a ListViewWrapper.

Fixed bug in request handling when incoming requests are attached to an existing response and the response is generated by directly accessing the res.servletResponse HttpServletResponse instance.

Go back to Java 1.4 compatibility. The few generics uses aren't worth it to require Java 1.5.

Made sub-properties updateable.

Logging improvements, such as an additional log message when a request starts evaluating, making commit log messages look nicer and easier to parse, and improved thread naming including thread ids in helma log messages.

Ampersand is no longer encoded as entity when encountered in macro tags.

Added support for secure and HttpOnly session cookies, with HttpOnly being enabled by default. The features are controlled through the httpOnlySessionCookie and secureSessionCookie app properties. We now compose and set the session cookie ourselves as this is the only reliable way to do it in a cross-servlet-container compatible way and without adding dependencies to the servlet container.

Fixed a problem with the code evaluation order of repositories added via app.addRepository().

Fixed app.xmlrpcCount to be increased for "new style" XML-RPC requests served by Jetty, fixing bug 629.

Ecmascript Harmony
maybe really brings the split in the TG1 TC-39 to an end
. More and more has gone into the 3.1 proposals over recent months while more and more has been taken out of the ES4 proposals. Looks like the gap became small enough to shift position TC-39 in a way where I think "3.1" will eventually probably be standardized as ES4, with what was still on the table for ES4 going into a future ES5 standard.

As part of Computerworld's series on "The A-Z of Programming Languages", Brendan Eich gave another interview on the state of Javascript and its history. It turned out to be one of the better ones.

Nothing new, except for the shifted timeline projection for ES3.1 and ES4, which Brendan now predicts to be Spring '09 for 3.1, with ES4 possibly being delayed until 2011. Since in the world of Javascript "implementation" comes before "standardization", this may not be as much of a change as it seems.

I just tried
the new Ganymede Eclipse release
, which includes JSDT, the fresh JavaScript IDE as part of the new 3.0 version of the Web Tools Project. Previously, I have been using the JSEclipse plugin because it was much snappier than the Javascript support in the WTP. According to my first impression with Ganymede, Javascript editing seems snappier compare to previous WTP versions I've tried, but still slower then JSEclipse, so I'm not yet sure whether I will stick with the new JSDT or install the JSEclipse plugin again.

Unfortunately, the JSDT doesn't have E4X support yet, that would have been a big selling point for me. On the plus side, it offers some pretty nifty code validation capabilities, making sure that objects and properties are defined, and which works over multiple files, similar to IntelliJ. Bending the code validation and completion features to work right for Helma development would be no trivial task, I'm sure, which makes these cool features less attractive for server-side Javascript development.

Your email address:
The "Decentralize" Newsletter
Exchanging ideas for building a
decentralized fabric of society.
Making true democracy work on a larger
scale while decentralizing "everything",
benefiting from local diversity and
global synergies at the same time.
http://tinyletter.com/zumbrunn