SmartFrog 3.12.006

This is a new release of SmartFrog, the Java-based, LPGL-licensed distributed deployment framework developed by HP Laboratories. SmartFrog enables applications to be deployed across multiple machines, configuring different aspects of the system so that they are all consistently configured, and managing the life-cycle of the application as a whole. The project's home page is http://smartfrog.org/

The release artifacts are available at http://sourceforge.net/project/showfiles.php?group_id=87384&package_id=176308

This release is 3.12.006; built from revision 5245 of the SVN repository. This release has an extended language with the ability to tag attributes, and includes the following items:

Packaging

This release is available as:

  1. RPM files inside a .tar.gz file.
  2. a JAR installer.
  3. the original core smartfrog distribution as .zip and .tar.gz (deprecated)

The RPM installation is for RPM-based Linux systems. It comprises three RPM files, smartfrog, smartfrog-daemon and smartfrog-demo:

smartfrog The core SmartFrog distribution.
smartfrog-daemon The shell scripts to add the smartfrog distribution to the path, and to run the daemon on start-up.
smartfrog-demo Example code and documentation
smartfrog-anubis Anubis partition-aware "tuple space"
smartfrog-logging Enhanced logging

All the JAR files are also published to a repository that is compatible with Apache Maven and Ivy. Add http://smartfrog.sourceforge.net/repository to your repository list to pull SmartFrog artifacts into your Ivy- or Maven- based build.

There are also SmartFrog components to retrieve artifacts from such a repository (the Library components under /org/smartfrog/services/os/java/library.sf ), which can be used for dynamic download of SmartFrog and other artifacts.

Security warning

Unless SmartFrog is configured with security, a running daemon will listen on its configured port for incoming deployment requests, and deploy the applications with the rights of the user running the daemon. When the smartfrog-daemon RPM is installed, that means that a process running as root will be listening on an open port for incoming deployment requests. Do not deploy SmartFrog this way on any untrusted network, not without turning security on and, ideally, recreating the RPMs with signed JAR files.

Building SmartFrog

SmartFrog requires Java 1.5 and Ant 1.7 to build.

The distribution does not include a source tree adequate to build the entire system. Please follow the instructions at http://sourceforge.net/svn/?group_id=87384 and check out smartfrog/trunk/core from our repository.

This release was built with revision 5245 of the repository, which is available under the SVN branch https://smartfrog.svn.sourceforge.net/svnroot/smartfrog/tags/release3.12.006

We strongly encourage anyone interested in building or extending smartfrog to get involved in the smartfrog developer mailing list, which can be found from the sourceforge project page http://sourceforge.net/projects/smartfrog/

Reporting Bugs

Please file all bug reports at http://jira.smartfrog.org/

The SmartFrog Team

Changes since last release

SFOS-486: Add property to SF CLI to be able to load descriptions from the filesystem when security is on

If you set the environment variable SFSECURERESOURCES_OFF=ENABLED, then resources can be loaded from unsigned JARs. In a daemon, this exposes in a security risk. In the client-side programs, this is a useful feature, as it means that even when SmartFrog is running in secure mode, it can parse and deploy SmartFrog descriptions from the local filesystem. In this case the client node itself must be trusted, as malicious deployment descriptors could be instantiated.

SFOS-357: Move Jetty support up to Jetty 6 (ongoing)

This release contains a preview of the Jetty-6 support in the Jetty component. This is not yet stable; anyone using Jetty under SmartFrog should remain with a previous release of SmartFrog 3.12. Be advised that one change is not backwards compatible: the Jetty component is no longer a compound; you can no longer nest servlet and web application components under Jetty. Removing this feature makes the lifecyle of the server and its children more deterministic, and produces more stable deployments.

However, it does mean that existing deployment descriptors will break. Plan for the change by moving all children of Jetty components into a Compound that deploys Jetty and its contents.

Bug

Improvement

New Feature

Task

Sub-task