Support for multiple registrations of Good

[cvillerm]

In an application and a required custom plugin we are creating, we would like the plugin to register Good to register its own reporters, but we would also like the application to register its own reporters.

As the application and the plugin are anyway independent, we cannot build a list of reporters and then register Good with this combined list.

I tested that when setting the Good register function multiple attribute to true, this seems to works fine, i.e. each reporter is registered and logging separately.

Is this way of registering Good multiple times supported?

Here is an example of code with the same Good+reporter registered twice:

const Hapi = require('hapi');
const server = new Hapi.Server();
server.connection({host: 'localhost', port: 8080});

const options = {
    reporters: {
        myConsoleReporter: [{
            module: 'good-squeeze',
            name: 'Squeeze',
            args: [{ log: '*', response: '*' }]
        }, {
            module: 'good-console'
        }, 'stdout']
    }
};

var Good = require('good');
Good.register.attributes.multiple = true;

server.register([{
    register: Good,
    options
},{
    register: Good,
    options
}], (err) => {

    if (err) {
        return console.error(err);
    }

    server.route({
        method: 'get',
        path: '/',
        handler: function(request, reply) {
            reply('ok');
        }
    });

    server.start(() => {
        console.info(`Server started at ${ server.info.uri }`);
    });

});

Accessing http://localhost:8080/ results in lines to be logged twice, as expected in this example:

170322/144859.910, [response] http://localhost:8080: get / {} 200 (21ms)
170322/144859.910, [response] http://localhost:8080: get / {} 200 (26ms)

[cvillerm]

To add to my question above "Is this way of registering Good multiple times supported?", if it is supported, could defining multiple: true in good packages attribute be accepted?

[arb]

My concern with allowing multiple is it's going to generate a lot of duplicate log entries. It's a little unusual for a plugin that is not mean for logging to require and register good and it's own reporting pipe-line.

[cvillerm]

@arb, thanks for your answer. This would create duplicate multiple log entries only if you register it multiple times with the same (or similar) reporters. The example I gave would obviously not be a typical one but is showing that it works without error. Even with a single registration, you can create multiple times a similar reporting pipeline when registering good, so it would also create duplicate logs. What you define is what you get...

The plugin we are creating would register its own Good reporting pipelines (with squeeze, formatters...) ending up sending logs over HTTPS to specific endpoints, so not duplicating any application specific logging (e.g. log to console, local file...) that the application would implement itself. Note that the plugin would be doing more than that, and it also needs to be registered, so we cannot restrict it to creating a Good reporter that the application would register directly as a Good reporting pipeline.

Technically, the way Good interacts with the "hapi framework" is mostly by registering event handlers, and nothing global that can create a conflict (like a route, route decoration or anything else global), so I don't see any potential conflict with something else.

[arb]

What happens if the app sets up good to listen for response events and strips out passwords. Your plugin also is set to listen for response events and send them off to your HTTPS endpoint, but you forget to strip passwords? This is just an example but something I could certainly see happening.

Rather than use good inside your plugin, maybe create a new event or something that good could listen for and emit it from your plugin. Just thinking out loud here...

[cvillerm]

The plugin (this is something that will be internal to our company) will document what it does in terms of reporting, so an application using it would decide if it is safe or not. Even without using Good and registering directly custom event (standard events) handlers, what would ensure the application that the plugin would strip passwords?

Note that the plugin needs to listen to standard request/response events. I am not talking about custom events. The idea was to reuse Good (and its standard way of defining reporting pipelines) in what the plugin does with such standard events, instead of reinventing the wheel internally.

[arb]

At this point in good's lifecycle, you're the first person to ever ask about multiple. That being said, I am very hesitant to make this change. Additionally, the code you posted above seems like a functional workaround right?

[cvillerm]

The problem with a workaround is that if eventually something is added in Good to make it no longer compatible with multiple registrations, we can be stuck without noticing it (as this wouldn't be considered as breaking from a Good viewpoint).

We would also like to use Glue for registering our plugins and I am wondering if such a way to customize Good package attributes could be compatible with it.

Lastly, we could likely wrap Good in another custom plugin that would take care of such attributes updates, as another more encapsulated workaround, but I was looking to avoid something becoming ugly.

[arb]

I'm going to close this. Again, this is the first request for multiple and registering good multiple times doesn't seem like the right way to solve this problem. If this comes up again, I will reconsider.

[danielkwinsor]

I see this as a benefit. Suppose library X wants to register event type Y with options: { includes: ['Z'] }, and another library wants to do ABC. I'm facing this now, but a solution of multiple registrations is not required, because I'm in the position of conjoining all these reporters and options. My reporters will work with a Good plugin registered with the same options, but could a conflict ever arise where some reporters need conflicting options?

And, if it wasn't clear, there's no urgency for me for this issue; I just wanted to provide this perspective.

[cvillerm]

I my case, I wanted to register good (with specific reporters) within a (custom) plugin and I still wanted an application to also register good itself with its own reporters, so combining reporters in a single registration of good wouldn't have worked. We anyway ended up not registering good within our custom plugin but registered directly to events and processed them without using good. Using good would have been simpler, but we couldn't.

[lock[bot]]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.