BugLogHQ 1.4 is now available
The newest release for BugLogHQ is now available for download at RIAForge. This new version has lots of new additions and improvements that will make it even more powerful and easier to use.
Here are some of the highlights of the new version:
» Asynchronous processing of bug reports and rules. I think this is the single most important feature of the release, so I'll go into a bit of detail here. In the previous versions every time the listener received a bug from another application it had to parse the bug, add one or more records to the database and process any rules that were defined; although this implementation responded very well (even collecting errors for a 30+ server deployment on a really high traffic website), it was obvious that this approach was not going to be very scalable, especially if many rules were defined for processing. So, on the new version the receiving and processing of bugs are two independent processes; that way BugLog can receive a bug and return a response to the caller application almost immediately since there is virtually no processing done at that time. It's responsibility of another process fired at regular intervals to process all bug reports on a queue along with any rules that are defined and this process can now takes its sweet time to do whatever it needs to do without the pressure of having to return a response to the caller application.
» Simplified Settings and Configuration Management. Now there is no need to hunt down and modify settings on multiple XML files, its just one config file now, and you may not even need to change it at all. And even better, there is now a "Settings" screen that lets you do anything from configure BugLog, to change your password, to add/delete/modify application users.
» JIRA Integration. This one came as a result of BugLogHQ being adopted by my employer to handle all bug reports for the applications/websites under our control, and since we use JIRA as our ticketing/planning tool, the option to submit bug reports as JIRA tickets was a no-brainer. If you use JIRA, then this one is for you, just go to the settings screen and enter the necessary info to connect to your JIRA instance and you are set. This also shows how easy it is to modify BugLogHQ to integrate with third party applications.
» Purge History option. This one has been a long time request of a lot of people. This option lets you delete all bug report entries older than X number of days. Simple but useful.
»Other new features include: user management, new 'firstMessageAlert' rule, bug fixes, and rule enabling/disabling
New BugLogHQ.com Website
Another good news is that www.BugLogHQ.com is now live! I wanted to create a small website to gather some documentation and resources for BugLog; many times people want to get some more information or more examples and I have to dig around to get some sample code to share. Right now it only contains the very basic info, but my plan is to let it grow according to the interests and needs of the buglog community. This site is in addition to the project page at RIAForge, which is still the main home for the project.
Upgrading From 1.3
If you are upgrading from 1.3, there are a couple of things you will need to do in order to preserve your data and settings.
On the DB side there is only one simple change which is the addition of a new column to the users table. You can find SQL scripts for this change under the install/migration/1_3_to_1_4 folder.
Also, if you have any rules defined, you may want to make a copy of /buglog/extensions/extensions.xml and once you install the new version put it on the /buglog/config folder. There is no need to make changes to that file.
Finally review the file /bugLog/buglog-config.xml.cfm to make sure your datasource, dbtype, (and dsn username and password if needed) are setup properly.
So, if you are an existing user of BugLog, you should really consider updating to the new version, and if you haven't used it before, try it - it really is a remedy to the million-error-emails-on-my-inbox syndrome.
I get no error messages, but it just never shows up in the summary or details page, and it stays empty.
I will use pastebin to show the code I am using...
http://crosenblum.pastebin.com/f227932c2
And then in my error handling page...
http://crosenblum.pastebin.com/f6a0f7fac
First, have you verified that buglog is correctly isntalled and working? You can do so by going to /buglog/test in your browser and running the two test scripts (client.cfm and server.cfm). That will tell you if there is anything wrong with your database or setup.
Now, there are a couple of things I see in your code that can explain why you don't see the bug reports. I take that the first snippet is from your Application.cfm. What I would recommend is to move your buglog service component initialization there, instead of doing it on your error handler. That way you deal with its settings on only one place and you can guarantee that it will always be available.
Also, on the error handler page, you have the call to notifyService enclosed on a cfcatch, so it will never be executed.
I suggest you modify your code as:
Application.cfm
<cfif not IsDefined("application.oBugLogService") or reset>
<cflock name="buglogservice" timeout="5" type="exclusive">
<cfset application.oBugLogService = createObject("component","bugLog.client.bugLogService").init(bugLogListener = _path_to_listener,apiKey = apiKey_if_any)>
</cflock>
</cfif>
Error handling page:
<cfif not IsDefined("application.oBugLogService")>
<cfset application.oBugLogService.notifyService(error.message, error)>
</cfif>
... the rest of your error handing template...
Also, there are a couple of things/tips to keep in mind:
1. Consider using Application.cfc and the onEror method for placing your call to buglog. That way it gets access to the full error details and can be submitted to buglog. From there you can include or redirect to any page you want to display an appropriate message to the user.
2. Keep in mind that the recommended setup for buglog is to place the buglog server and listener on a separate server, and only include the client cfc with your app. That way if your application is failing you are not adding additional load with all the error processing.
Let me know if you have any questions,
Oscar
Thanks for help...
http://crosenblum.pastebin.com/m5a97e5ef there is my code
My goal is to get it so that any normal errors get sent to buglog, then we can get a feel for what errors are persistent, ones created by user inaccuracies, and ones that are just wildly occur.
But so far, no luck getting any data sent to the service. The database, datasource is all setup. I see no database errors indicating problems sending data to the bugLog database. Just nothing...
In order for buglog to receive the errors you have to explicitly submit them to it, it is not going to "magically" trap any error that happens just by itself. Now there are a couple of things you can do on your site to allow buglog to receive any error that happens. Basically the idea is to have a single place to handle errors for your entire app and place the buglog call there. You can do this they way I pointed a couple of comments above, by either using Application.cfc's onError method, or using an <cferror /> tag on your Application.cfm. Both of these approaches allow you to indicate a template or code block to execute whenever an error happens on your site, so the only thing you need to do is put the call to buglog's notifyService() there.
Now, if you are already doing this and you still not seeing any errors, you may want to check the coldfusion logs for any errors on the buglog application itself. Also, you can check for any errors if you look at the buglog queue. You do that by click on the small icon on the right of the label "BugLogListener Service is Running (Stop)" in the Buglog main app. If you click there you will se a "Message Log" showing any messages or errors that happen.
If you'd like to take the discussion off the blog and share more details about your app, feel free to email me at oarevalo at gmail dot com