Helma

Besides configuring servlets and contexts in Jetty with an XML file conforming to a special syntax proprietary to Jetty the servlet API provides a more standard approach with so-called web applications and web.xml. This approach provides further ... [More] control of defining contexts and additional features like e.g. filters. AFAIK, it was developed for easier deployment and exchange of such web applications between different server/servlet engines; but as all of this was designed for the mystical realm of the so-called Java enterprise edition (J2EE) I am only an educated boy making educated guesses. Following are the basic steps to define a web application with Jetty and Helma 1.x. Prerequisites Patched Helma for running Jetty with XML configurationjasper-runtime.jar and jasper-compiler.jar Copy the two Jasper JAR files into the lib/ext directory of your Helma installation. Setting up jetty.xml Before starting up Helma we need to define the web application in jetty.xml. For a start we take the manage application as example: <Call name="addWebApplication"> <Arg> /manage </Arg> <Arg> /path/to/helma/apps/manage </Arg> </Call> You could simply add the snippet above to the example jetty.xml but of course it also should work with only one listener and with different settings as well. In fact, the main configuration of the application takes place in a another XML file called web.xml that needs to be stored in a special directory under ./apps/nameOfHelmaApp – the infamous WEB-INF directory. In the case of the manage application this is /path/to/helma/apps/manage/WEB-INF/web.xml, although it works with any other path as well as long as it is correctly defined in the second argument of <Call name="addWebApplication"> (ie. without the WEB-INF/web.xml part which is appended automatically). Setting up web.xml As already mentioned, web applications and their XML configuration syntax span another whole new world which I find extraordinarily hard to get adequate documentation for. Here is a quite good one, actually written as web.xml reference guide for Tomcat. For setting up a Helma application a very reduced configuration looks like this: <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <display-name> test </display-name> <servlet> <servlet-name> manage </servlet-name> <servlet-class> helma.servlet.EmbeddedServletClient </servlet-class> <init-param> <param-name> application </param-name> <param-value> manage </param-value> </init-param> <!-- init-param> <param-name> cookieDomain </param-name> <param-value> .domain.tld </param-value> </init-param --> </servlet> <servlet-mapping> <servlet-name> manage </servlet-name> <url-pattern> /* </url-pattern> </servlet-mapping> </web-app> This defines the Helma manage application as a web application which will be displayed as "test" (e.g. in the list of available contexts) and which will be mounted under the context path defined in jetty.xml (/manage) considering the URL pattern /*. Thus, everything located under /manage/* will be delegated to the manage application. To get an idea how further servlet options are defined I included the setting of cookieDomain in comments. Anything, that can be set in the initialization of the helma.servlet.EmbeddedServletClient class can be defined accordingly. Cave at I noticed that everytime I start up Helma with a web application context I get an exception on shutdown: Exception in thread "Thread-3" java.lang.NullPointerException at helma.util.Logging.closeAll(Logging.java:167) at helma.util.Logging.shutdown(Logging.java:159) at helma.main.Server.stop(Server.java:543) at helma.main.HelmaShutdownHook.run(HelmaShutdownHook.java:36) [Less]

To obtain better control over Jetty in a Helma installation the following patch enables Jetty to be configured from an XML file called jetty.xml in Helma's installation directory. An example file is provided, too, configuring a NCSA log file, a ... [More] generic listener on port 8080, an AJP listener on port 8009, a static context for Helma's static directory, a password protected context running two Jetty servlets as well as an SSL listener on port 8443. For the latter one, you also need the jetty.keystore file which contains two self-signed certificates for the host names 127.0.0.1 and localhost. To try it out apply the patch to the Helma source and drop the other two attached files into the Helma installation directory. You should disable any definitions of HTTP or AJP ports in the start script or properties file to avoid interference with Helma's settings. The patch adds the argument -c defining the location of the configuration file to the launcher.jar command-line invocation: java -jar launcher.jar -c jetty.xml After restarting Helma you still should be able to connect to Helma either directly via http://localhost:8080 or from within Apache (e.g. using mod_jk or mod_proxy_ajp) via http://localhost:8009 The secure server should be available via https://localhost:8443 – you probably need to define some security exceptions in your browser due to the self-signed certificates. More information about the XML configuration capabilities is available at the Jetty 5 site. I did not find official API docs for this version, only these ones at http://www.dpml.net/api/jetty/5.1.6/. nametypesizejetty.xmltext/xml6812 bytesjetty.keystoreapplication/octet-stream2491 bytesjettyXmlConfiguration.patchapplication/octet-stream8427 bytes [Less]

The only reason why I make such a fuss about how to configure web applications with Jetty and Helma is the option of using servlet filters in web applications. Especially the UrlRewriteFilter drew my attention because rewriting URLs is currently the ... [More] only missing feature imagining Antville.org running without the great Apache webserver and with Jetty only...* Anyway, here's outlined how I made Jetty do the same what Apache 2.0 currently does at Antville.org. * Why I would imagine such a thing, you ask? I guess it's partly performance tweaking, partly pure curiosity. Prerequisites Helma patched and configured to run web applicationsUrlRewriteFilter 3.1.0 sourcePatch fixing functions in Url Rewrite Filter Apply the patch to the Java source of UrlRewriteFilter and compile by invoking ant dist-jar. The resulting JAR file is located in the ./dist/urlrewrite-3.1.0/webapp/WEB-INF/lib/ directory and needs to be moved to Helma's lib/ext directory. (Alternatively to the linked patch above you also can use the one provided in the attachments or simply copy the attached urlrewrite-3.1.0.jar file in Helma's lib/ext directory.) nametypesizeUrlRewriteFilter-fixFunctions.patchapplication/octet-stream1352 bytesurlrewrite-3.1.0.jarapplication/octet-stream146591 bytesurl-rewrite-for-web.xmltext/xml1388 bytes Enabling UrlRewriteFilter Add the contents of the attached file url-rewrite-for-web.xml to the desired web application configuration file web.xml (in some WEB-INF directory). The configuration prompts the web application to reload a file called rewrite.xml (also located in the WEB-INF directory) every 60 seconds. This file contains the rewrite rules (see below). Furthermore, it defines the URL path /rewrite-status dumping the current status of the UrlRewriteFilter for debugging. Defining Rewrite Rules The syntax for the rewrite rules of UrlRewriteFilter are very well documented in the corresponding manual. Here's the basic content of the rewrite.xml file I started with for emulating the current Apache rewrite rules at Antville.org: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 2.6//EN" "http://tuckey.org/res/dtds/urlrewrite2.6.dtd"> <urlrewrite> <rule> <from> ^/helma/static/antville(.*)$ </from> <to> /helma/static/antville$1 </to> </rule> <rule> <condition type="server-name"> ^(?:www\.)?antville\.org$ </condition> <from> ^/(.*)$ </from> <to> /helma/antville/$1 </to> </rule> <rule> <condition type="server-name"> ^[^.] \.antville\.org$ </condition> <from> ^/(.*)$ </from> <to> /helma/antville/${replace:%{server-name}:.antville.org:}/$1 </to> </rule> </urlrewrite> Its main purpose is to rewrite any Antville.org URL by appending the server part (ie. the foo in foo.antville.org) after the basic path /helma/antville/, and thus, enabling host-based weblogs. Defining Rewrite Rules mod_rewrite Style Although it says in the manual that UrlRewriteFilter rules can be defined with the syntax used by Apache and the mod_rewrite module I did not manage to get the filter working like this. Instead, I always get the same output of rewrite-status as described in this posting to the UrlRewriteFilter discussion group. If someone else is more successful here please let me know. (However, I guess it's a bug in UrlRewriteFilter we will have to wait for being fixed.) [Less]

Helma 1.6 Helma 1.6.2 is the current stable version of Helma and was released on April 7, 2008. You can get it from the download page. See the Helma 1.6.0 Changelog, Helma 1.6.1 Changelog and Helma 1.6.2 Changelog for new features and bugfixes in ... [More] Helma 1.6. The next planned release is Helma 1.6.3, for which we currently have a release candidate with the changes mentioned in the Helma 1.6.3 Changelog. Helma 1.7 Later, Helma 1.7 will introduce new features to those found in Helma 1.6. See pages tagged with helma 1.7 for a list of planned features and the list of fixes and changes on track for Helma 1.7. Helma 2.0 The roadmap for Helma 2 is being reassessed, since functionality that was intended for Helma 2 has now already been included in the Helma 1.6.0 release and development of Helma 1.x has been reenergized. The implementation of Helma 2 has already been started, and is currently continuing under the code name "Helma NG", likely in parallel with the development of future Helma 1.x versions. [Less]

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 ... [More] Helma is now again backwards compatible with Java 1.4, to mention just a few. See the Helma 1.6.3 Changelog for more detailed information about the changes. Now, please go download Helma 1.6.3rc1 and let us know in case something in these packages isn't ready for prime time! [Less]

To store your HopObjects into a relational database system you need to define a database mapping. This is done in the type.properties files located in the persistent HopObject's prototype directory (e.g. apps/myApp/MyPrototype). The type.properties ... [More] files contain no JDBC connection information, which is located in the db.properties file in the Helma installation directory. Configuration Settings Database related _db = datasourceName The _db entry describes the database source to use for managing objects of this type. datasourcename is the connection's name defined in the db.properties, which is located in Helma’s installation directory or the application directory. The db.properties file contains information about the JDBC connections, like the JDBC driver, the connection URL and the database username and password. _table = tableName The _table entry tells Helma which table to use for objects of this type within the database. To avoid problems with reserved words of SQL or your database system you should prefix your table names. (e.g. T_Story for the Story prototype’s table) _prototype = prototypeColumnName Helma can store multiple prototypes into one single database table. This feature could be useful if you extend prototypes for inheritance and if you want to store all sub-prototypes into the same table. To enable this feature just add a column to the table where Helma can store the prototype’s name. This column is referenced in the type.properties of the affected prototype. This picture shows a database table where Animals and Dogs could be stored. A Dog is a sub-prototype of the Animal prototype. It inherits every property from the Animal and defines two new properties called "Breed" and "Color". Note: The Dog’s type.properties just defines the two new properties. All other stuff will be inherited from the Animal. _extensionId = String or Integer If you extend a prototype, Helma will use the name of the sub-prototype as value for the _prototype database column. This could slow down the performance. Better would be to choose a numeric value, which result faster index retrievals and queries. You can define this numeric value in the _extensionId property of the sub-prototype. Example: If Helma needs all cats, the db-layer can filter all animals with the value '260486'. The value '260486' is defined in the cat’s type.properties as _extensionId! For dogs the _extensionId is set to a 'dogu dugu' string. Animals’ type.properties defines no _extensionId, so Helma uses the prototype’s name, which is 'Animal'! Download the animal demo application: nametypesizetypeproperties_prototype.pngimage/png12229 bytestypeproperties_prototype_helma.pngimage/png7529 bytestypeproperties_prototype_extensionid.pngimage/png10996 bytesdemo_animalfarm.zipapplication/zip3156 bytes Inheritance _extends = Prototype The _extends entry engages Helma to inherit properties, functions and skins from another prototype. This can be compared to Java’s subclassing mechanism. For example could be a Dog's _extends value the Animal, which inherits to the Dog prototype basic properties like father or mother, some skins and standard functions like getBiologicalClassification() Object Management _id = primaryKeyColumnName The _id entry defines the column to use as primary key. Helma requires a single primary key with no other functionality. You can read this unique ID from the _id-property of the HopObject. _parent = localPropertyName, localProperty.parentsCollectionName, root.collectionName The _parent entry contains a comma-separated list of properties of objects of this type to be used as parent. Objects must know their parent in order to generate correct URLs in their href() function. If a property in the list is null, Helma will look on the following one to fetch a parent object. If an entry in the _parent item does not contain a dot, it is interpreted as an object property of the current object that acts as the object's parent. If an entry contains a dot character, the part after the dot is interpreted as a collection in the parent object in which the current object is contained. Alternatively or additionally, a second or third dot separated part may indicate an object reference instead or in addition to a collection or mountpoint. If the _parent is specified as "root", it is not interpreted as a property of the current object. Instead, the application's root object is used as parent object. _children Simple Properties simplePropertyName = DB_COLUMN_NAME A simple property maps a property name of the object to a column of the database table. The type of the table's column need not be specified. Helma does all necessary conversion when reading or writing a property value. simplePropertyName.readonly = true Makes the property read only and initializes it with the value from the database. simplePropertyName.private = true The private flag forces Helma to update this column only in the database, but prevents any updates on collections and references containing the modified object. Referenced Objects obj = object(SomeHopObject) obj.local obj.foreign obj.local.X obj.foreign.X obj.logicalOperator Collections coll = collection(SomeHopObject) coll.local coll.foreign coll.loadmode coll.cachemode coll.order coll.filter coll.filter.additionalTables coll.hints coll.maxSize coll.accessname coll.group coll.group.order coll.group.prototype Mountpoints moutpointName = mountpoint(SomeTransientHopObject) [Less]

HelmaLib HelmaLib is included with standard Helma installations and is a Javascript library considered to be of universal usefulness for all Helma application development. It consists of two modules, a core module that extends core Javascript ... [More] prototypes and a "helma" module that contains additional prototypes, providing additional functionality not provided directly by Helma's core environment. Jala Jala is an open-source collection of JavaScript modules for Helma Object Publisher, written and maintained by ORF.at and licensed under the Apache 2.0 License. Jala modules include support for GNU gettext compatible internationalization, asynchronous request dispatching, HopObject collection rendering, and much more. knallgrauLib The knallgrauLib is a collection of methods, utilities and guidances, as well as third party libraries, that should make the daily life of a Helma developer easier. It is written and maintained by Knallgrau, and released to the public under a BSD-style license. HelmaSwarm HelmaSwarm is a tool to build Helma clusters, a group of Helma instances forming one virtual server. HelmaSwarm uses asynchronous JGroups communication to distribute/coordinate cache and session state. HelmaGroups HelmaGroups is a Helma extension that puts several helma servers into a group and makes them share data in their memory over the network. A new global object "group" is added to the scripting environment and all changes in that object tree are immediately replicated to all members. Rhinola and mod_gcj Rhinola is a very thin server-side JavaScript execution framework running on top of mod_gcj, a module for Apache to run Java code via GCJ directly within the web server. Rhinola is a fresh implementation of a Helma core and formed the basis for the development of the Helma 2.0 development branch. Rabbit Rabbit is a framework that provides a clean and simple way to script the object-data structure of a Helma application and automates the mapping of that object structure to a relational database, including the automatic setup of that database. Warp Warp repository is a repository providing virtual prototype directories and type.properties files based on existing database schemas. You need to have correct primary and foreign keys set in your database for this to work. JavaScript Template Engine, Velocity and FreeMarker A flexible templating engine that is written entirely in Javascript and is backwards compatible with Helma 1.5 skins and macros, but adds additional statements such as loops and conditionals. The JavaScript Template Engine is implemented as a library for Helma 1.5. It has not yet been updated to be compatible with the new features added to Helma 1.6 skins and macros. For those looking for even more templating alternatives, Jürg Lehni also implemented two Helma extensions. VelocityExtension is a Helma extension that integrates Velocity, a powerful open source template engine into Helma and FreeMarkerExtension is a Helma extension that integrates FreeMarker, another powerful open source template engine into Helma. Gobi A dynamic wikiesque web site framework built on Helma. Gobi aims to provide a platform for Wiki applications as well as applications including Wiki-like features and provides simple yet powerful base classes that can be extended to do any imaginable thing. Antville Antville is an expandable weblog hosting system built on Helma that has some of the features of a full grown content management system. Antville scales very well up to several thousands of weblogs and is very easy to use while offering a lot of advanced features that make it even capable for hosting other types of websites. Twoday A feature rich, industry-proven blog hosting software based on Antville. Twoday is the software running at twoday.net, a german-speaking weblog hosting platform hosted and developed by Knallgrau. Knallgrau also offers an extended commercial version called Twoday Media. OpenMocha A soft-coding web site framework built on Helma. OpenMocha web applications are written through a web-based interface that wraps pieces of server-side and client-side code around content objects. These behaviors are inherited by other child objects in the hierarchical content tree and can be overridden at any level. AppJet Another browser based soft-coding framework, offered as a hosting service. The AppJet site itself runs on Helma, providing the environment in which the apps are developed, while the resulting apps themselves are served directly from a custom developed Rhino virtualization engine. Chopper Chopper is a client-side Javascript library that provides methods and features to emulate the Helma scripting environment on the client-side. It effectively allows you to write client-side applications the way you would write them on the server-side using Helma. Junction Junction is a Rails-like, offline-capable MVC framework that runs both client side on the browser and server-side on top of Helma. It synchronizes code and RDBMS between the two sides. On the client-side it leverages Google Gears. Axiom Axiom is a commercial fork based on Helma, a framework with a JSR-170 compliant embedded database, support for TALE templates and many other out-of-the-box features. CouchDB Joshua Paine ported the CouchDB javascript lib to run on the Helma server-side. CouchDB is a document database server, accessible via a RESTful JSON API, which is what this Helma server-side lib leverages. [Less]

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.

The Helma 1.6.3rc3 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 ... [More] 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. The totalUploadLimit value is now also applied to ordinary form post requests. Now uses LinkedHashMap for property updates to preserve insertion order. Running Helma apps through helma.servlet.StandaloneServletClient within a servlet container was made easier by avoiding a direct dependency of helma.main.Server on Jetty. 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. 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. [Less]

The third release candidate can be taken for a spin. See the Helma 1.6.3 Changelog for detailed information about the changes included in this new version. Release Candidate 3 contains some additional important changes, such as the totalUploadLimit ... [More] 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. [Less]