radar 0.3.0 → 0.4.0
Sign up to get free protection for your applications and to get access to all the features.
- data/.gitignore +2 -1
- data/CHANGELOG.md +21 -0
- data/Gemfile +3 -2
- data/Gemfile.lock +47 -48
- data/README.md +14 -25
- data/docs/user_guide.md +155 -30
- data/examples/rack/config.ru +1 -1
- data/examples/sinatra/README.md +15 -0
- data/examples/sinatra/example.rb +18 -0
- data/lib/radar.rb +11 -5
- data/lib/radar/application.rb +14 -3
- data/lib/radar/backtrace.rb +42 -0
- data/lib/radar/config.rb +112 -20
- data/lib/radar/data_extensions/rack.rb +4 -21
- data/lib/radar/data_extensions/rails2.rb +31 -0
- data/lib/radar/data_extensions/request_helper.rb +28 -0
- data/lib/radar/exception_event.rb +10 -4
- data/lib/radar/integration/rails2.rb +31 -0
- data/lib/radar/integration/rails2/action_controller_rescue.rb +30 -0
- data/lib/radar/integration/rails3.rb +0 -2
- data/lib/radar/integration/rails3/railtie.rb +0 -2
- data/lib/radar/integration/sinatra.rb +21 -0
- data/lib/radar/matchers/local_request_matcher.rb +43 -0
- data/lib/radar/reporter/hoptoad_reporter.rb +204 -0
- data/lib/radar/reporter/logger_reporter.rb +2 -3
- data/lib/radar/version.rb +1 -1
- data/radar.gemspec +1 -0
- data/test/radar/application_test.rb +39 -18
- data/test/radar/backtrace_test.rb +42 -0
- data/test/radar/config_test.rb +49 -4
- data/test/radar/data_extensions/rails2_test.rb +14 -0
- data/test/radar/exception_event_test.rb +9 -0
- data/test/radar/integration/rack_test.rb +1 -1
- data/test/radar/integration/sinatra_test.rb +13 -0
- data/test/radar/matchers/local_request_matcher_test.rb +26 -0
- data/test/radar/reporter/hoptoad_reporter_test.rb +20 -0
- data/test/radar/reporter/logger_reporter_test.rb +0 -4
- metadata +41 -12
data/.gitignore
CHANGED
data/CHANGELOG.md
CHANGED
@@ -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",
|
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
|
data/Gemfile.lock
CHANGED
@@ -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.
|
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
|
19
|
-
actionpack (= 3.0.0
|
12
|
+
actionmailer (3.0.0)
|
13
|
+
actionpack (= 3.0.0)
|
20
14
|
mail (~> 2.2.5)
|
21
|
-
actionpack (3.0.0
|
22
|
-
activemodel (= 3.0.0
|
23
|
-
activesupport (= 3.0.0
|
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.
|
22
|
+
rack-mount (~> 0.6.12)
|
29
23
|
rack-test (~> 0.5.4)
|
30
|
-
tzinfo (~> 0.3.
|
31
|
-
activemodel (3.0.0
|
32
|
-
activesupport (= 3.0.0
|
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
|
36
|
-
activemodel (= 3.0.0
|
37
|
-
activesupport (= 3.0.0
|
38
|
-
arel (~> 0.
|
39
|
-
tzinfo (~> 0.3.
|
40
|
-
activeresource (3.0.0
|
41
|
-
activemodel (= 3.0.0
|
42
|
-
activesupport (= 3.0.0
|
43
|
-
activesupport (3.0.0
|
44
|
-
arel (0.
|
45
|
-
activesupport (
|
46
|
-
bluecloth (2.0.
|
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.
|
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.
|
55
|
+
rack-mount (0.6.13)
|
62
56
|
rack (>= 1.0.0)
|
63
|
-
rack-test (0.5.
|
57
|
+
rack-test (0.5.6)
|
64
58
|
rack (>= 1.0)
|
65
|
-
rails (3.0.0
|
66
|
-
actionmailer (= 3.0.0
|
67
|
-
actionpack (= 3.0.0
|
68
|
-
activerecord (= 3.0.0
|
69
|
-
activeresource (= 3.0.0
|
70
|
-
activesupport (= 3.0.0
|
71
|
-
bundler (
|
72
|
-
railties (= 3.0.0
|
73
|
-
railties (3.0.0
|
74
|
-
actionpack (= 3.0.0
|
75
|
-
activesupport (= 3.0.0
|
76
|
-
rake (>= 0.8.
|
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
|
-
|
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.
|
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
|
-
|
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://
|
6
|
-
*
|
7
|
-
|
8
|
-
Radar is
|
9
|
-
errors in your
|
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
|
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.
|
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://
|
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
|
data/docs/user_guide.md
CHANGED
@@ -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
|
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.
|
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.
|
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.
|
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.
|
128
|
-
app.
|
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.
|
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.
|
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.
|
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
|
196
|
-
responds to `report` and takes a single {Radar::ExceptionEvent} as a parameter
|
197
|
-
|
198
|
-
|
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.
|
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.
|
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?`
|
323
|
-
|
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
|
328
|
-
|
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, "
|
403
|
+
app.match ErrorMessageMatcher, "Hello"
|
344
404
|
end
|
345
405
|
|
346
|
-
|
406
|
+
Both of the above result in the following behavior:
|
347
407
|
|
348
408
|
raise "Hello, World" # not reported
|
349
|
-
raise "
|
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.
|
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.
|
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.
|
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.
|
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
|