The latest relese has the usual assortment of bug fixes, minor updates, trivial enhancements and two big features. These are web root deployment and "named instances". Installing BugLog on the Web Root Web root deployment means that with this release you can now take your bugLog archive and expand it right on the root of your website without doing extensive refactorings. This is a feature that lots of people have requested and tried to make it work themselves. The "default" behavior of BugLog is still to expect it to be deployed on a directory named "bugLog" on your server, and actually if you deploy it elsewhere, it will still create an application mapping named "bugLog" so that it can find its own components. Now, if you want to put the application in the root, the only change you need to make is on the main config file (located in config/buglog-config.xml.cfm). Locate the line:

and replace it with: That is the only change. As a side note, with this version you can use the general.externalURL setting in cases in which you want to explicitly provide buglog with it's own external URL. By default bugLog looks at the CGI scope and infers its public URL from there. This is used when creating links on emails and when setting up the scheduled tasks. For most cases this works fine, but sometimes you might want to override this and provide your own URL (i.e. if your buglog is on a cluster behind a load balancer) Named Instances The purpose of a "named instance" is to easily allow having multiple independent instances of BugLog working at the same time on the same server and each with their own configuration but reusing (as much as possible) the same codebase. The idea here is that for example you might want to have a separate bugLog for development and another for production. Each buglog would point to their own database and have their own rules and configuration. Typically thiw would require dedicating a separate server or VMs for each BugLog server, however this is sometimes not practical or cost effective. With named instance, you can have the main BugLog to collect only production bugs, and then have a second instance (on the same server) only for your applications in development/testing/qa/etc. You can have any number of instances on the same server. Obviously the more instances you add, the more load you put on the server, so keeping them to a small number would be better. So how do you create a new instance? well, BugLog tries to make this process very easy for you. A named instance is a just a subdirectory of your web root with a few files in it. The name of the subdirectory becomes the name of the instance. To create a new instance just copy the contents of /bugLog/install/named-instance-template into a different directory on your server. For example, if you want to have an instance named "buglogdev" you should end up with the following directory tree:

/
  /bugLog/
    ... the buglog app lives here ...
  /buglogdev/
    /config/
      buglog-config.xml.cfm
    Application.cfc
    index.cfm
    listener.cfc
    listener.cfm

After copying the files, edit Application.cfc to give a proper name to your Application. Also now you can edit your instance's own buglog-config.xml.cfm to give it its own configuration (typically this consists on indicating a different datasource). Once that is done, you can now visit /buglogdev on your browser and you will see the familiar BugLogHQ application. Also, note that the listeners for your new instance have different endpoints: /buglogdev/listener.cfm for the REST listener, and /buglogdev/listener.cfc?wsdl for the SOAP listener. As always, you can checkout the google groups mailing list at http://groups.google.com/group/bugloghq if you need any help, have suggestions or find any bugs that need to be fixed. Have fun! Update: Added links to RiaForge and GitHub