Server-Side Javascript Standard Library

Kevin Dangoor asks what Server Side JavaScript needs and launches more talk about a standard library for Javascript on the server-side.

Having a unified API for libraries in different environments would in my opinion be nice especially because it would allow higher level modules to be shared between different server-side javascript environments. One problem that has slowed this from happening in the past has been that in Java-based environments like Helma , Sling and Xjs , Rhino makes the direct scripting of Java packages so easy, that some stakeholders don't believe the added burden of maintaining an additional API layer in javascript is reasonable for the benefit they would get from it.

Some pointers to current server-side javascript library projects in the realm of the Helma project and to other efforts for a standard library for JS:

The current Helma 1 versions come with two libraries containing several modules. The HelmaLib provides modules for core functionality such as Database, File, Ftp, Http, Smtp and SSH, some that extend built-in prototypes, and a few others. The Jala library adds further modules such as DNS, MP3 and XML-RPC and utility modules such as i18n, image manipulation, captcha, HtmlDocument, RemoteContent, Podcast, Rss and other XML related modules.

Modules are included either via a configuration file or at runtime via a method call. A module is only loaded once, even if included multiple times. In the context of Helma 1, modules are loaded into the global scope and they need to be nice and restrict themselves to a save namespace.

For Helma NG , the way modules are included is changed to eliminate any possible namespace conflicts. Each module in Helma NG lives in its own scope and can selectively import other modules or portions thereof into its scope. Here again, when modules are imported in different scopes, each module is only actually loaded once.

There has been some discussion with the goal of a unified library/ modules architecture between different projects over in the Helma NG group. One of the major goals in Peter Michaux's xjs project is to provide a standard library and a shared module loading mechanism.

First Soleil on Mont-Soleil

Le premier Soleil sur le Mont-Soleil dans le soleil de soirée: "The Twins" - a siamese warrior or siamese warriors?

Rhinola 0.8 - Server JS reduced to the minimum

Hannes took a few days time to bring mod_gcj and rhinola up to date and prepared new releases for both projects . mod_gcj now implements a pretty useful subset of the servlet specification. Rhinola no longer depends on mod_gcj and can be deployed on any servlet container. Have a look at the release notes for details.

mod_gcj is an Apache module to run Java code as closely embedded into the HTTP server as possible using the GCC/GCJ Java runtime and libraries. GCJ treats Java as just another language and compiles it down to native code. This makes it much lighter than most traditional Java virtual machines, especially regarding memory footprint and startup time.

Rhinola is a servlet based web scripting environment using the Mozilla Rhino JavaScript implementation . It was originally conceived as showcase and playground for the mod_gcj Apache module, but it should work with any servlet container. Rhinola is not a full featured server side JavaScript Runtime. If you are looking for something conceptually similar but more complete, have a look at Helma NG.

Helma turns 1.6.3

Helma is 1.6.3 and ready to be downloaded ! With over 10 years of development history, she is now more mature and more stable than ever. The latest list of refinements is a testament to that. The release isn't as minor as it sounds. Helma is just very conservative about her version numbers. This is really more like a 6.3 release than a 1.6.3. She is ready for your projects! For those of you that haven't already, it is now time to get serious about Javascript on the server-side .

Helma 1.6.3-rc3 ready for testing

The third release candidate can be taken for a spin . Again, see the Helma 1.6.3 Changelog for an updated list ofchanges included in the new version.

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.

Helma 1.6.3 Release Candidate 2

A second release candidate is ready to download . Please take a moment to check for any remaining problems with these packages.

See the Helma 1.6.3 Changelog for detailed information about the changes included in this new version.

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.

Our bugzilla has a list of bugs fixed in Helma 1.6.3 .

• 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.

Now, please go download Helma 1.6.3rc1 and let us know in case something in these packages isn't ready for prime time!

>>> Helma at the 2008 OpenExpo in Zurich