After several months of closed beta and internal use on live projects, we’re pleased to announce LogDigger Connector 2.0 and accompanying My LogDigger service.

LogDigger Connector 2.0

LogDigger library has been completely redesigned. Here’s what’s new:

• Single jar, no external dependencies.
• Support for multiple logging frameworks (v1.0 worked with Log4j only).
• Configure using simple DSL.
• You can write your own extensions that, for example, capture application data or handle collected logs and context data.
• Included extensions can send captured error details by email or to My LogDigger service.

My LogDigger service

My LogDigger is an error monitoring hub. It will collect and automatically classify error reports received, notify you when new error occurs and help you dig into error report details. A typical web application error report created by the connector library may include:

1. HTTP request details, including URL and POST parameters
2. List of request and session attributes
3. Application specific data (current user for example)
4. Request log

Here’s how error details page looks like:

Discontinuing support for LogDigger Server

You’ve probably already noticed that our focus for the last several months was on the BugDigger – out hosted service for contextual bug reporting that integrates with Atlassian JIRA, Basecamp, FogBugz and other popular issue trackers.

It’s no secret that we were able to provide much better support for the hosted service than for downloadable server software like LogDigger Server is. With the hosted service we’re able to fix eventual integration issues and deploy a fix in a matter of hour or less. Many LogDigger Server users have figured out this also and already migrated to BugDigger.

So, discontinuing LogDigger Server was somewhat tough decision but we believe it’s a step in the right direction and that we’ll be able to provide our users with a better service and products without LogDigger Server pulling us back. All LogDigger Server users under the maintenance will receive either free BugDigger subscription for a year or a free license for BugDigger for JIRA.

We’re aware that BugDigger doesn’t offer all features of LogDigger Server. For those users interested in capturing Java logs we’ll have some nice surprises in the following weeks.

Announcing BugDigger for JIRA

BugDigger for JIRA offers more or less equivalent features the hosted service but is available as a standalone JIRA plugin! Combined with the latest release of browser add-on, BugDigger for JIRA automatically fills your JIRA issues with contextual bug information such as:

• screen shot of the webpage
• the current URL
• recently visited pages on the site
• browser details and operating system version

In addition, BugDigger for JIRA includes annotation editor that you can use to edit any image attached to an issue. All file uploads are handled automatically.

Besides the maximum level of compatibility with JIRA (works on version 4.1 and above), BugDigger plugin has few additional benefits:

• works with any JIRA authentication mechanism and
• can be used with JIRA instances running behind a firewall.

By the end of month we have a special introductory offer: use coupon EARLYBIRD14 on a BugDigger for JIRA license purchase and get up to 50% off – the sooner you buy the bigger discount you get.

If you have any feedback for the BugDigger team, please contact us. We’re very interested in hearing your feedback, suggestions for improvements and feature requests.

We’re very excited today. After several months of development and beta testing, our BugDigger service is finally going live!

The initial release of BugDigger allows users to easily capture bugs in their web applications and send them to an external bug tracker. Bug reports submitted via BugDigger include:

• The browser and version number used
• The URL where the issue occurred
• Recently opened URLs
• Screenshot of the web page

Automatically captured screenshot can be further edited using built-in Flash-based image editor.

How BugDigger differs from LogDigger Server?

1. BugDigger is a hosted solution. No troubles any more installing LogDigger Server, backing up database, etc. All you need is BugDigger browser add-on.
2. BugDigger supports ad-hoc bug reporting. Use it on any site, any time, without need for installing logdigger.xml and starting data collection.
3. BugDigger does not log full site usage history (e.g. POST data and intermediate screenshots while you use a web site are not collected).

Yes, these are significant differences but we believe that hosted solution with currently available set of features is sufficient for majority of users.

What does this mean for the future of LogDigger Server?

We admit that LogDigger Server have been neglected for the several months. (For example, BugDigger already has better compatibility with the latest releases of JIRA and Redmine.) For the following months we plan a series of updates that will make LogDigger and BugDigger closer to each other:

• There’s LogDigger Connector 2.0 release waiting for some polishing,
• BugDigger will start accepting application logs,
• One browser extension will be compatible with both BugDigger and LogDigger Server.

Priority of our steps depends pretty much on feedback we receive from community. So, if you have any comment we’d love to hear from you.

Today we’ve released an updated extension for IE with an important bug fix. Some users have experienced an issue where LogDigger was not uploading screen shots. Well, this was easy to fix once we reproduced it. Anyway, if you’ve experienced this issue, go ahead and download LogDigger extension for IE v1.0.2.

P.S. For those of you that use BugDigger, note that we’ve already ported this fix to its IE extension (v1.9.2).

We’ve released LogDigger Server 1.1.1 today that:

• Fixes compatibility issue with JIRA 4.1,
• Has improved annotation editor that automatically resizes to take the full visible area of the browser window.

Since our first release of LogDigger Server we are aware that the biggest issue in adoption of LogDigger is the server setup and resources it needs. For the last several months we’ve been working on a hosted solution and today we’re pleased to announce our BugDigger service.

Our focus with BugDigger was to enable users to report web application issues with as little effort as possible.

So, how BugDigger is different from LogDigger? Although they are conceptually very similar, there are some important differences:

1. It’s very easy to get started as we host the server for you. No troubles any more setting up and backing up database, upgrading LogDigger Server, etc. All you need is a BugDigger add-on for your browser.
2. There is no need to to install logdigger.xml on tested web sites. You can click the report button at any time for any visited web site and BugDigger will collect environment details, recent site usage history and web page screenshot.
3. At this time BugDigger does not track submitted POST data and does not collect server logs.

BugDigger is currently in open beta and completely FREE. Start using it today!

BugDigger browser extensions are not currently compatible with LogDigger Server. (You would have to uninstall LogDigger extension before installing BugDigger.) In the following months we’ll be extending both BugDigger and LogDigger Server to support about the same set of features using the same browser extension.

For the curious, the BugDigger service is hosted on Google’s App Engine infrastructure. We hope to benefit from Google’s dedication and expertise in cloud maintenance so we can focus on providing you with better tools and service.

We are pleased to announce the official release of LogDigger Server 1.1. There are several long awaited improvements and fixes so let’s start…

Improved issue trackers integration

We’ve fixed quite severe issue affecting integration with JIRA installations having complex issue types schemes. If you were unable to get issue reporting form in LogDigger for your JIRA project, there are big chances that you’ve been affected by this issue.

Beside the above mentioned, one of the quite annoying issues with the LogDigger Server v1.0 was its inability to collect errors reported by the issue tracker and show them to user. Although LogDigger recognizes required issue reporting fields, it doesn’t know their meaning so validation on the issue tracker may fail. This has been fixed so now you should see an error in the LogDigger’s issue reporting form as it comes from the issue tracker.

We feel very confident with the current level of compatibility with supported issue trackers, especially with Atlassian JIRA. (We admin giving JIRA more attention but, at least so far,  JIRA’s user community was quite vibrant, providing us with a necesary feedback and, well… reporting bugs in LogDigger Server.)

Setup and Operating modes

Simplified setup process allows you to choose the operating mode for your LogDigger Server instance:

• The Tracker Mode is tied to an external issue tracker, reusing its users, access control and issue reporting configuration.
• The Standalone Mode allows you to register users (and enable self-registration) on your LogDigger Server. Combined with the new emailing feature, this mode allows you to submit bug reports to any issue tracker accepting reports via email.
• The Open Mode is a simple, open access mode suitable for single-user installations.

It’s also worth to mention that default LogDigger Server’s home directory (that defaults to ~/.logdigger) used for configuration files, logs, etc. now can be changed using Java system properties.

Sending issue reports by email

Connecting LogDigger Server with your outgoing (SMTP) mail server, for each project you can choose to send issue reports to one or more email addresses. Emails sent by LogDigger server contain the complete issue report with attached screenshot and server logs (where available).

Other changes

Among a number of small fixes and improvements in v1.1, here are some that we hope will make your use of LogDigger easier:

• Fixed an issue with annotation image editor on Linux,
• On the project page you can obtain ready to use logdigger.xml for your project.
• In administration pages you can see the full path of configuration and log files used by the LogDigger Server.
• LogDigger Server will warn you if it’s running on a low memory (as it may seriously affect performance).

Migrating from LogDigger Server 1.0

There are no special upgrade tasks that you need to do. The LogDigger Server will automatically upgrade database created by the previous version. Just in case, we highly recommend that you make a database backup before upgrading.

If you’re using LogDigger Server for Windows, make sure to uninstall LogDigger Server 1.0 before installing 1.1.

And yes… hoping that you’ve switched to an enterprise grade database already, don’t forget to copy and install database driver jar file.

We hope you’ll like this update. As always, feel free to contact us with any problem, question or comment you may have.

We thought we did a decent job documenting LogDigger components, especially LogDigger Connector library (because the first public version was released about a year ago). Well, this is quite embarrassing but, thanks to a user asking for help, we’ve discovered that the LogDigger Connector manual and distribution available for download were not synchronized.

The problem was affecting those trying to save Java application logs on the LogDigger Server. If you’ve tried to do this and got an error in your your application:

java.lang.ClassNotFoundException: com.logdigger.connector.servlet.filter.LogDiggerClientFilter

well… it was our mistake, not yours. We sincerely apologize. The manual was listing class names available in LogDigger Connector 1.0.1 that renamed class RequestLoggerFilter to LogDiggerClientFilter. However, as we’ve discovered, download page was still pointing to v1.0. This is fixed now. (We’re aware that this kind of class renaming is not a good practice but we wanted to do it synchronized with the release of LogDigger Server because no one could use this class before anyway. We obviously failed to do this properly and, believe us, we’ve learned a lesson.)

We’re sorry about this omission and, if you experienced the above described problem, hope you’ll give the LogDigger Connector library one more chance. As always, feel free to contact us with any questions you may have.

We released updates for the LogDigger Server and browser extensions today, addressing few issues:

• Browser extensions have got hard limit on an image size they send to the LogDigger Server. If the image is bigger that this, it will be scaled down.
• By default, on bug reporting, screenshot will be created for the visible part of the page only, not for the full page as earlier.
• The console for server log monitoring in IE has been disabled by default. It can be re-enabled in the LogDigger Preferences dialog. IE should be restarted for changes to take effect.
• Fixed compatibility issues with the SQL Server.

We’ve released the LogDigger Server v1.0.2 with the fix for an issue affecting integration with some JIRA 3 installations. The LogDigger was failing to login user in cases when JIRA was showing only the full username in the Dashboard page, without the user’s login ID.

We sincerely apologize to everyone affected and hope that the update will work much better for them.

The latest version of LogDigger Server can be downloaded here.