radar 0.3.0 → 0.4.0

Sign up to get free protection for your applications and to get access to all the features.
Files changed (38) hide show
  1. data/.gitignore +2 -1
  2. data/CHANGELOG.md +21 -0
  3. data/Gemfile +3 -2
  4. data/Gemfile.lock +47 -48
  5. data/README.md +14 -25
  6. data/docs/user_guide.md +155 -30
  7. data/examples/rack/config.ru +1 -1
  8. data/examples/sinatra/README.md +15 -0
  9. data/examples/sinatra/example.rb +18 -0
  10. data/lib/radar.rb +11 -5
  11. data/lib/radar/application.rb +14 -3
  12. data/lib/radar/backtrace.rb +42 -0
  13. data/lib/radar/config.rb +112 -20
  14. data/lib/radar/data_extensions/rack.rb +4 -21
  15. data/lib/radar/data_extensions/rails2.rb +31 -0
  16. data/lib/radar/data_extensions/request_helper.rb +28 -0
  17. data/lib/radar/exception_event.rb +10 -4
  18. data/lib/radar/integration/rails2.rb +31 -0
  19. data/lib/radar/integration/rails2/action_controller_rescue.rb +30 -0
  20. data/lib/radar/integration/rails3.rb +0 -2
  21. data/lib/radar/integration/rails3/railtie.rb +0 -2
  22. data/lib/radar/integration/sinatra.rb +21 -0
  23. data/lib/radar/matchers/local_request_matcher.rb +43 -0
  24. data/lib/radar/reporter/hoptoad_reporter.rb +204 -0
  25. data/lib/radar/reporter/logger_reporter.rb +2 -3
  26. data/lib/radar/version.rb +1 -1
  27. data/radar.gemspec +1 -0
  28. data/test/radar/application_test.rb +39 -18
  29. data/test/radar/backtrace_test.rb +42 -0
  30. data/test/radar/config_test.rb +49 -4
  31. data/test/radar/data_extensions/rails2_test.rb +14 -0
  32. data/test/radar/exception_event_test.rb +9 -0
  33. data/test/radar/integration/rack_test.rb +1 -1
  34. data/test/radar/integration/sinatra_test.rb +13 -0
  35. data/test/radar/matchers/local_request_matcher_test.rb +26 -0
  36. data/test/radar/reporter/hoptoad_reporter_test.rb +20 -0
  37. data/test/radar/reporter/logger_reporter_test.rb +0 -4
  38. metadata +41 -12
data/.gitignore CHANGED
@@ -3,4 +3,5 @@ pkg/*
3
3
  .bundle/*
4
4
  doc/*
5
5
  .yardoc/*
6
- test.rb
6
+ test.rb
7
+ _site/*
@@ -1,3 +1,24 @@
1
+ ## 0.4.0 (October 5, 2010)
2
+
3
+ - Added a `LocalRequestMatcher` to detect local requests for web
4
+ applications. [GH-27]
5
+ - Added rejecters, which are the opposite as matchers. If any rejecter
6
+ matches, then the error is not reported.
7
+ - You can now enable reporters, data extensions, etc using the singular
8
+ version: `app.reporter`, `app.data_extension`, etc. [GH-25]
9
+ - Rails 2 integration added.
10
+ - Sinatra integration documented.
11
+ - Reporters can now take just a block which takes a single parameter
12
+ `event`.
13
+ - Matchers can now take just a block which takes a single parameter `event`. [GH-24]
14
+ - Added a `Hoptoad` reporter! Radar is now a drop-in replacement for
15
+ Hoptoad. [GH-21]
16
+ - Fixed issue with `LoggerReporter` not being able to use the Rails
17
+ logger.
18
+ - The backtrace in an `ExceptionEvent` is now a `Backtrace` object,
19
+ which is a subclass of Array. This is because backtraces are now
20
+ parsed to extract the file, line, and method of each entry.
21
+
1
22
  ## 0.3.0 (August 21, 2010)
2
23
 
3
24
  - Added `KeyFilter` to filter out specific keys in the data hash.
data/Gemfile CHANGED
@@ -7,11 +7,12 @@ gemspec :path => File.expand_path("../", __FILE__)
7
7
  # Additional gems which I don't really want in the gemspec but
8
8
  # are useful for development
9
9
  group :development do
10
- gem "yard", :git => "http://github.com/lsegal/yard.git", :ref => "bf84275"
10
+ gem "yard", "~> 0.6.1"
11
11
  gem "bluecloth"
12
12
  end
13
13
 
14
14
  group :examples do
15
15
  gem "rack"
16
- gem "rails"
16
+ gem "rails", "~> 3.0.0"
17
+ gem "sinatra", "~> 1.0.0"
17
18
  end
@@ -1,55 +1,49 @@
1
- GIT
2
- remote: http://github.com/lsegal/yard.git
3
- revision: bf84275
4
- ref: bf84275
5
- specs:
6
- yard (0.6.0.rc1)
7
-
8
1
  PATH
9
2
  remote: .
10
3
  specs:
11
- radar (0.3.0)
4
+ radar (0.4.0)
5
+ builder (~> 2.0)
12
6
  json (>= 1.4.6)
13
7
 
14
8
  GEM
15
9
  remote: http://rubygems.org/
16
10
  specs:
17
11
  abstract (1.0.0)
18
- actionmailer (3.0.0.rc)
19
- actionpack (= 3.0.0.rc)
12
+ actionmailer (3.0.0)
13
+ actionpack (= 3.0.0)
20
14
  mail (~> 2.2.5)
21
- actionpack (3.0.0.rc)
22
- activemodel (= 3.0.0.rc)
23
- activesupport (= 3.0.0.rc)
15
+ actionpack (3.0.0)
16
+ activemodel (= 3.0.0)
17
+ activesupport (= 3.0.0)
24
18
  builder (~> 2.1.2)
25
19
  erubis (~> 2.6.6)
26
20
  i18n (~> 0.4.1)
27
21
  rack (~> 1.2.1)
28
- rack-mount (~> 0.6.9)
22
+ rack-mount (~> 0.6.12)
29
23
  rack-test (~> 0.5.4)
30
- tzinfo (~> 0.3.22)
31
- activemodel (3.0.0.rc)
32
- activesupport (= 3.0.0.rc)
24
+ tzinfo (~> 0.3.23)
25
+ activemodel (3.0.0)
26
+ activesupport (= 3.0.0)
33
27
  builder (~> 2.1.2)
34
28
  i18n (~> 0.4.1)
35
- activerecord (3.0.0.rc)
36
- activemodel (= 3.0.0.rc)
37
- activesupport (= 3.0.0.rc)
38
- arel (~> 0.4.0)
39
- tzinfo (~> 0.3.22)
40
- activeresource (3.0.0.rc)
41
- activemodel (= 3.0.0.rc)
42
- activesupport (= 3.0.0.rc)
43
- activesupport (3.0.0.rc)
44
- arel (0.4.0)
45
- activesupport (>= 3.0.0.beta)
46
- bluecloth (2.0.7)
29
+ activerecord (3.0.0)
30
+ activemodel (= 3.0.0)
31
+ activesupport (= 3.0.0)
32
+ arel (~> 1.0.0)
33
+ tzinfo (~> 0.3.23)
34
+ activeresource (3.0.0)
35
+ activemodel (= 3.0.0)
36
+ activesupport (= 3.0.0)
37
+ activesupport (3.0.0)
38
+ arel (1.0.1)
39
+ activesupport (~> 3.0.0)
40
+ bluecloth (2.0.9)
47
41
  builder (2.1.2)
48
42
  erubis (2.6.6)
49
43
  abstract (>= 1.0.0)
50
44
  i18n (0.4.1)
51
45
  json (1.4.6)
52
- mail (2.2.5)
46
+ mail (2.2.6.1)
53
47
  activesupport (>= 2.3.6)
54
48
  mime-types
55
49
  treetop (>= 1.4.5)
@@ -58,41 +52,46 @@ GEM
58
52
  rake
59
53
  polyglot (0.3.1)
60
54
  rack (1.2.1)
61
- rack-mount (0.6.9)
55
+ rack-mount (0.6.13)
62
56
  rack (>= 1.0.0)
63
- rack-test (0.5.4)
57
+ rack-test (0.5.6)
64
58
  rack (>= 1.0)
65
- rails (3.0.0.rc)
66
- actionmailer (= 3.0.0.rc)
67
- actionpack (= 3.0.0.rc)
68
- activerecord (= 3.0.0.rc)
69
- activeresource (= 3.0.0.rc)
70
- activesupport (= 3.0.0.rc)
71
- bundler (>= 1.0.0.rc.1)
72
- railties (= 3.0.0.rc)
73
- railties (3.0.0.rc)
74
- actionpack (= 3.0.0.rc)
75
- activesupport (= 3.0.0.rc)
76
- rake (>= 0.8.3)
59
+ rails (3.0.0)
60
+ actionmailer (= 3.0.0)
61
+ actionpack (= 3.0.0)
62
+ activerecord (= 3.0.0)
63
+ activeresource (= 3.0.0)
64
+ activesupport (= 3.0.0)
65
+ bundler (~> 1.0.0)
66
+ railties (= 3.0.0)
67
+ railties (3.0.0)
68
+ actionpack (= 3.0.0)
69
+ activesupport (= 3.0.0)
70
+ rake (>= 0.8.4)
77
71
  thor (~> 0.14.0)
78
72
  rake (0.8.7)
79
73
  shoulda (2.11.3)
80
- thor (0.14.0)
74
+ sinatra (1.0)
75
+ rack (>= 1.0)
76
+ thor (0.14.3)
81
77
  treetop (1.4.8)
82
78
  polyglot (>= 0.3.1)
83
- tzinfo (0.3.22)
79
+ tzinfo (0.3.23)
80
+ yard (0.6.1)
84
81
 
85
82
  PLATFORMS
86
83
  ruby
87
84
 
88
85
  DEPENDENCIES
89
86
  bluecloth
87
+ builder (~> 2.0)
90
88
  bundler (>= 1.0.0.rc.5)
91
89
  json (>= 1.4.6)
92
90
  mocha
93
91
  rack
94
92
  radar!
95
- rails
93
+ rails (~> 3.0.0)
96
94
  rake
97
95
  shoulda
98
- yard!
96
+ sinatra (~> 1.0.0)
97
+ yard (~> 0.6.1)
data/README.md CHANGED
@@ -2,34 +2,23 @@
2
2
 
3
3
  * Source: [http://github.com/mitchellh/radar](http://github.com/mitchellh/radar)
4
4
  * IRC: `#vagrant` on Freenode
5
- * User Guide: [http://mitchellh.github.com/radar/file.user_guide.html](http://mitchellh.github.com/radar/file.user_guide.html)
6
- * Documentation: [http://mitchellh.github.com/radar](http://mitchellh.github.com/radar)
7
-
8
- Radar is a tool which provides a drop-in solution to catching and reporting
9
- errors in your Ruby applications in customizable ways.
10
-
11
- Radar is not a typical exception notifier such as Hoptoad and Exceptional
12
- since the former are built with Rails apps in mind, logging to a central
13
- server. Instead, Radar was initially built for [Vagrant](http://vagrantup.com),
14
- a command line tool. And instead of solely logging to a central server,
15
- Radar supports logging in configurable ways (to a file, to a server, to
16
- a growl notification, etc.)
17
-
18
- Radar was built out of the need for an easy automated solution to catching
19
- exceptions and gathering information, since I noticed that every time a stack
20
- trace was outputted for [Vagrant](http://vagrantup.com), I was asking the
21
- user all the same questions which could've easily have been gathered automatically.
22
- Now, Vagrant users can simply send me the radar output and I don't have to
23
- ask for any more information 90% of the time.
5
+ * User Guide: [http://radargem.com/doc/file.user_guide.html](http://radargem.com/doc/file.user_guide.html)
6
+ * Website: [http://radargem.com](http://radargem.com)
7
+
8
+ Radar is an ultra-configurable exception reporting library for Ruby which
9
+ lets you report errors in your applications any way you want. Read about
10
+ the [rationale behind Radar](http://radargem.com/rationale.html).
24
11
 
25
12
  ## Brief Feature Breakdown
26
13
 
27
14
  - Reporters allow Radar to report anywhere: a file, a server, email, etc.
28
- - Data extensions to add additional contextual data to exceptions
29
- - Matchers to filter exceptions which Radar reports
15
+ - Data extensions enable you to add additional contextual data to exceptions
16
+ - Matchers are able to filter which exceptions are reported
17
+ - Filters remove sensitive data from exceptions
30
18
  - Run multiple Radar "applications" side-by-side to catch and report
31
- different exceptions to different places
32
- - Integration with 3rd party software: Rack, Rails 3.
19
+ different exceptions to different places.
20
+ - Integration with 3rd party software: Rack, Rails 2, Rails 3, and Sinatra.
21
+ - Drop-in replacement and integration with [Hoptoad](http://hoptoadapp.com)
33
22
 
34
23
  ## Quick Start
35
24
 
@@ -38,7 +27,7 @@ ask for any more information 90% of the time.
38
27
  Then just begin logging exceptions in your application:
39
28
 
40
29
  r = Radar::Application.new(:my_application)
41
- r.reporters.use :file
30
+ r.reporter :file
42
31
  r.report(exception)
43
32
 
44
33
  You can also tell Radar to attach itself to Ruby's `at_exit` hook
@@ -87,7 +76,7 @@ look it up later anywhere in your application:
87
76
  ## Documentation and User Guide
88
77
 
89
78
  For more details on configuring Radar, please view the
90
- [user guide](http://mitchellh.github.com/radar/file.user_guide.html), which
79
+ [user guide](http://radargem.com/doc/file.user_guide.html), which
91
80
  is a detailed overview of Radar and all of its features.
92
81
 
93
82
  ## Reporting Bugs and Requesting Features
@@ -11,7 +11,7 @@ breakdown of Radar:
11
11
  - Matchers to filter exceptions which Radar reports
12
12
  - Run multiple Radar "applications" side-by-side to catch and report
13
13
  different exceptions to different places
14
- - Integration with 3rd party software: Rack, Rails 3.
14
+ - Integration with frameworks: Rack, Rails 2, Rails 3, and Sinatra.
15
15
 
16
16
  ## Installation
17
17
 
@@ -40,7 +40,7 @@ remote server, etc.). Radar comes with some built-in reporters. Below, we config
40
40
  the application to log errors to a file (by default at `~/.radar/errors/my_application`):
41
41
 
42
42
  Radar::Application.new(:my_application) do |app|
43
- app.reporters.use :file
43
+ app.reporter :file
44
44
  end
45
45
 
46
46
  ### Reporting Errors
@@ -69,6 +69,14 @@ Now, whenever your application is about to crash (an exception not caught by
69
69
  a `rescue`), Radar will catch your exception and report it just prior to
70
70
  crashing.
71
71
 
72
+ ### Framework Integration
73
+
74
+ Radar provides framework integration out of the box for Rack, Rails 2, Rails 3, and
75
+ Sinatra. These all require little or no extra configuration to your Radar
76
+ applications.
77
+
78
+ For more information on framework integration, see the [framework integration section](#__toc__section33).
79
+
72
80
  ## Terminology
73
81
 
74
82
  Although you've already seen a basic example, I think its a good idea to
@@ -108,14 +116,14 @@ of what this means with a few examples:
108
116
  Reporters are enabled using the appilication configuration:
109
117
 
110
118
  Radar::Application.new(:my_application) do |app|
111
- app.reporters.use :file
119
+ app.reporter :file
112
120
  end
113
121
 
114
122
  And can be configured by passing a block to the reporter, which is yielded with
115
123
  the instance of that reporter:
116
124
 
117
125
  Radar::Application.new(:my_application) do |app|
118
- app.reporters.use :file do |reporter|
126
+ app.reporter :file do |reporter|
119
127
  reporter.output_directory = "~/.radar/exceptions"
120
128
  end
121
129
  end
@@ -124,8 +132,8 @@ Radar also allows multiple reporters to be used, which are then called
124
132
  in the order they are defined when an exception occurs:
125
133
 
126
134
  Radar::Application.new(:my_application) do |app|
127
- app.reporters.use FileReporter
128
- app.reporters.use AnotherReporter
135
+ app.reporter FileReporter
136
+ app.reporter AnotherReporter
129
137
  end
130
138
 
131
139
  As you can see from the above examples, a reporter takes both a symbol
@@ -147,7 +155,7 @@ where `timestamp` is the time that the exception occurred and `uniquehash` is th
147
155
  The directory where these files will be stored is configurable:
148
156
 
149
157
  Radar::Application.new(:my_application) do |app|
150
- app.reporters.use :file do |reporter|
158
+ app.reporter :file do |reporter|
151
159
  reporter.output_directory = "~/my_application_errors"
152
160
  end
153
161
  end
@@ -174,7 +182,7 @@ page.
174
182
  any IO object (`stdout`, `stderr`, a net stream, etc.).
175
183
 
176
184
  Radar::Application.new(:my_application) do |app|
177
- app.reporters.use :io, :io_object => STDOUT
185
+ app.reporter :io, :io_object => STDOUT
178
186
  end
179
187
 
180
188
  #### LoggerReporter
@@ -185,17 +193,44 @@ existing logging system, or if you simply want a backup for your exceptions (e.g
185
193
  report to both a server and a logger).
186
194
 
187
195
  Radar::Application.new(:my_application) do |app|
188
- app.reporters.use :logger, :log_object => Logger.new(STDOUT), :log_level => :error
196
+ app.reporter :logger, :log_object => Logger.new(STDOUT), :log_level => :error
189
197
  end
190
198
 
191
199
  `log_level` will default to `:error` if not specified.
192
200
 
201
+ #### HoptoadReporter
202
+
203
+ {Radar::Reporter::HoptoadReporter HoptoadReporter} sends an exception event to
204
+ the [Hoptoad service](http://hoptoadapp.com). If Radar is integrated with a Rack
205
+ or Rails application, then the reporter will automatically add request information
206
+ to the Hoptoad notice as well.
207
+
208
+ Radar::Application.new(:my_application) do |app|
209
+ app.reporter :hoptoad, :api_key => "your_key_here"
210
+ end
211
+
212
+ There are many other options which can be set, though `api_key` is the only required
213
+ one. See the class docs for more information.
214
+
215
+ **Note:** Due to a limitation of the Hoptoad service, only a very specific
216
+ set of data can be sent to the service. Therefore, your data extension information
217
+ likely won't be sent to Hoptoad.
218
+
193
219
  ### Custom Reporters
194
220
 
195
- It is very easy to write custom reporters. A reporter is simply a class which
196
- responds to `report` and takes a single {Radar::ExceptionEvent} as a parameter.
197
- Below is an example of a reporter which simply prints out that an error
198
- occurred:
221
+ It is very easy to write custom reporters. A reporter is either a class which
222
+ responds to `report` and takes a single {Radar::ExceptionEvent} as a parameter,
223
+ or it is a lambda function which takes a single {Radar::ExceptionEvent} as a
224
+ parameter. Below is an example of a lambda function reporter which simply
225
+ prints out that an error occurred to `stdout`:
226
+
227
+ Radar::Application.new(:my_application) do |app|
228
+ app.reporter do |event|
229
+ puts "An exception occurred! Message: #{event.exception.message}"
230
+ end
231
+ end
232
+
233
+ And the same example as above except implemented using a class:
199
234
 
200
235
  class StdoutReporter
201
236
  def report(event)
@@ -203,10 +238,8 @@ occurred:
203
238
  end
204
239
  end
205
240
 
206
- And then using that reporter is just as easy:
207
-
208
241
  Radar::Application.new(:my_application) do |app|
209
- app.reporters.use StdoutReporter
242
+ app.reporter StdoutReporter
210
243
  end
211
244
 
212
245
  ## Data Extensions
@@ -241,7 +274,7 @@ Data extensions are enabled via the application configuration like most other
241
274
  things:
242
275
 
243
276
  Radar::Application.new(:my_application) do |app|
244
- app.data_extensions.use UnameExtension
277
+ app.data_extension UnameExtension
245
278
  end
246
279
 
247
280
  ### Built-In Data Extensions
@@ -317,15 +350,44 @@ Examples of each are shown below (in the above order):
317
350
  app.match :class, StandardError, :include_subclasses => true
318
351
  app.match :class, /.*Error/
319
352
 
353
+ #### `:local_request`
354
+
355
+ A matcher which matches if a web request came from a local address. This
356
+ matcher requires that a remote IP be available at `event.to_hash[:request][:remote_ip]`
357
+ (which is set by the Rack and Rails data extensions if you're using it
358
+ in any framework).
359
+
360
+ Examples of how it can be used below:
361
+
362
+ app.match :local_request
363
+ app.match :local_request, :remote_ip_getter => Proc.new { |event| event.to_hash[:my_ip] }
364
+ app.match :local_request, :localhost => /^192\.168\.0\.1$/
365
+
366
+ Usually the defaults are what you want. Also, this matcher is more useful
367
+ as a rejecter, typically, since you don't want local requests during
368
+ development firing off exception reports:
369
+
370
+ app.reject :local_request
371
+
320
372
  ### Custom Matchers
321
373
 
322
- Matchers are simply classes which respond to `matches?` which returns a boolean
323
- noting if the given {Radar::ExceptionEvent} matches. If true, then the exception
374
+ Matchers are simply classes which respond to `matches?` or a lambda function,
375
+ both of which are expected to take a single {Radar::ExceptionEvent} as a
376
+ parameter and must return a boolean `true` or `false. If true, then the exception
324
377
  is reported, otherwise other matchers are tried, or if there are no other matchers,
325
378
  the exception is ignored.
326
379
 
327
- Below is a simple custom matcher which only matches exceptions with the
328
- configured message:
380
+ Below is a simple custom matcher which only matches exceptions with a
381
+ specific message, implemented using a lambda function:
382
+
383
+ Radar::Application.new(:app) do |app|
384
+ app.match do |event|
385
+ event.exception.message == "Hello"
386
+ end
387
+ end
388
+
389
+ And now the same matcher as above is implemented using a class, with a
390
+ little more flexibility:
329
391
 
330
392
  class ErrorMessageMatcher
331
393
  def initialize(message)
@@ -337,16 +399,37 @@ configured message:
337
399
  end
338
400
  end
339
401
 
340
- And the usage is shown below:
341
-
342
402
  Radar::Application.new(:app) do |app|
343
- app.match ErrorMessageMatcher, "sample message"
403
+ app.match ErrorMessageMatcher, "Hello"
344
404
  end
345
405
 
346
- And this results in the following behavior:
406
+ Both of the above result in the following behavior:
347
407
 
348
408
  raise "Hello, World" # not reported
349
- raise "sample message" # reported since it matches the message
409
+ raise "Hello" # reported since it matches the message
410
+
411
+ As you can see, for quick, easy matchers, lambda functions are the way to
412
+ go and provide an easy solution to matching. However, if you need more
413
+ customizability or complex logic, classes are the ideal solution.
414
+
415
+ ### Rejecters
416
+
417
+ Matchers are useful for setting up a whitelist of exactly what is allowed
418
+ to be reported. Sometimes it is more useful to setup a blacklist, instead
419
+ (or a combination of the both). "Rejecters" is the term given to the blacklist,
420
+ although they use the exact same matchers as above. The only difference is
421
+ that if any of the rejecters match, then the error is not reported.
422
+
423
+ Another important difference is that rejecters take precedence over matchers.
424
+ This means that even if a matcher would have matched the exception, if
425
+ a rejecter matches it, then the exception will never be reported by Radar.
426
+
427
+ Using rejecters is the exact same as matchers, and use the exact same
428
+ classes:
429
+
430
+ Radar::Application.new(:app) do |app|
431
+ app.reject :backtrace, "my_file.rb"
432
+ end
350
433
 
351
434
  ## Filters
352
435
 
@@ -363,7 +446,7 @@ The easiest way, if the filtering is really simple, is to just
363
446
  use a lambda. Below is a small example:
364
447
 
365
448
  Radar::Application.new(:my_app) do |app|
366
- app.filters.use do |data|
449
+ app.filter do |data|
367
450
  data.delete(:password)
368
451
  data
369
452
  end
@@ -386,7 +469,7 @@ there is more complex logic in the filtering. The class must respond to
386
469
  end
387
470
 
388
471
  Radar::Application.new(:my_app) do |app|
389
- app.filters.use MyPasswordFilter
472
+ app.filter MyPasswordFilter
390
473
  end
391
474
 
392
475
  This does the same thing, functionally, as the previous lambda example. However,
@@ -402,7 +485,7 @@ data and replaces it with specified text ("[FILTERED]" by default). Below we
402
485
  configure the key filter to filter passwords:
403
486
 
404
487
  Radar::Application.new(:my_app) do |app|
405
- app.filters.use :key, :key => :password
488
+ app.filter :key, :key => :password
406
489
  end
407
490
 
408
491
  Then, assuming an exception is raised at some point and the following event data
@@ -431,7 +514,7 @@ catch any exceptions by the rack application:
431
514
  require "radar"
432
515
 
433
516
  app = Radar::Application.new(:my_app)
434
- app.reporters.use :io, :io_object => STDOUT
517
+ app.reporter :io, :io_object => STDOUT
435
518
 
436
519
  use Rack::Radar, :application => app
437
520
  run YourWebApp
@@ -452,6 +535,24 @@ of only the additional information is shown below:
452
535
  }
453
536
  }
454
537
 
538
+ ### Rails 2
539
+
540
+ Radar can integrate with any Rails 2 application to automatically
541
+ catch any exceptions thrown by actions as well as provide additional
542
+ information capture when the exception is raised. First, add the `radar`
543
+ dependency to your environment (via a `Gemfile` or `environment.rb`) and
544
+ make sure it is installed. Then create an initializer in `config/initializers/radar.rb`
545
+ to create your application:
546
+
547
+ Radar::Application.new(:my_app) do |app|
548
+ # Enable any reporters here and configure the app as usual
549
+
550
+ # Integrate with rails 2
551
+ app.integrate :rails2
552
+ end
553
+
554
+ Radar will immediately begin to catch and report any errors.
555
+
455
556
  ### Rails 3
456
557
 
457
558
  Radar can integrate very easily with any Rails 3 application to automatically
@@ -470,6 +571,30 @@ steps to take to setup Radar. Radar will already work with your application at t
470
571
  but it won't report to anywhere by default, so at the very least you must
471
572
  open up `config/initializers/radar.rb` and add a reporter.
472
573
 
574
+ ### Sinatra
575
+
576
+ Radar can easily integrate with Sinatra, since Sinatra is built on top of
577
+ Rack. Below is a very simple example Sinatra application showing Radar
578
+ integration:
579
+
580
+ require "rubygems"
581
+ require "sinatra"
582
+ require "radar"
583
+
584
+ # First define the Radar application, like normal.
585
+ Radar::Application.new(:my_app) do |app|
586
+ # ...
587
+ end
588
+
589
+ # And the Sinatra application
590
+ class MyApp < Sinatra::Base
591
+ use Rack::Radar, :application => Radar[:my_app]
592
+
593
+ get "/" do
594
+ raise "BOOM!"
595
+ end
596
+ end
597
+
473
598
  ## Internals Logging
474
599
 
475
600
  Radar provides a lightweight internal log which logs information which