This fixes around a bug in BaseComponent.prototype.loadConfig where
your config won't be processed unless your filter has some specific
configuration.
only_type and only_field_* params are implicitly processed by
BaseComponent.prototype.loadConfig, but loadConfig has a "do we
need to load config" check at the top of the function that might fail,
at which point the implicit options is ignored.
For example, a custom filter
filter://my_thing://only_type=syslog. my_thing doesn't need any
other parameters, so it's constructor looks like
function FilterMyThing() {
base_filter.BaseFilter.call(this);
this.mergeConfig({
name: 'MyThing'
});
}
In the previous implementation, BaseComponent.prototype.loadConfig
will decide no config needs to be loaded, ignore the only_type
param, and my_thing filter will apply to all messages.
This patch removes the if statement, and re-indents. The loadConfig
function is only called once when the filter is loaded, so any
performance penalty by processing all the options is a one-time cost.
This fixes around a bug in
BaseComponent.prototype.loadConfig
where your config won't be processed unless your filter has some specific configuration.only_type
andonly_field_*
params are implicitly processed byBaseComponent.prototype.loadConfig
, butloadConfig
has a "do we need to load config" check at the top of the function that might fail, at which point the implicit options is ignored.For example, a custom filter
filter://my_thing://only_type=syslog
.my_thing
doesn't need any other parameters, so it's constructor looks likeIn the previous implementation,
BaseComponent.prototype.loadConfig
will decide no config needs to be loaded, ignore theonly_type
param, andmy_thing
filter will apply to all messages.This patch removes the if statement, and re-indents. The
loadConfig
function is only called once when the filter is loaded, so any performance penalty by processing all the options is a one-time cost.