Release Candidate 3 contains some additional important changes, such as the totalUploadLimit value now being applied also to ordinary form post requests, as well as preventing a potential problem with the insertion order and making it easier to run Helma in other servlet containers.
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.
Relative repository paths now resolve relative to Helma home directory, fixing bug 639.
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.
Unified macro error handling, no longer dumping stack traces for macro errors.
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.
Changed code to not track unset() on non-persitable properties, fixing bug 633.
Fixed serialization for transient HopObjects.
Synchronize more methods in TypeManager as well as app.addRepository() to avoid memory race conditions.
Use LinkedHashMap for dirty node tracking to preserve insertion order.
Made checkXmlRpc work with content-types containing a charset subheader, fixing bug 628.
Continue parsing macro tags even if it is a comment. This is the only way we can correctly catch embedded macros. Fixes bug 588.
Only resolve direct prototype matches in parent chain, fixing bug 617.
A few more minutes, and CERN, which already was the coolest place on the planet
because it's where the Web was born
, will be literally the coolest place on the planet when they switch on
the Large Hadron Collider
and start pumping out those man made black holes.
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.
