On Mon, 2016-04-18 at 16:42 +0200, Alexandre Trufanow wrote:
> I agree, logging events would be a good solution for this use case.
>
You can add this back with a re-usable class with the API as-is:
class log_handler : public proton::handler {
virtual void log_event(const std::string& name) {
cerr << "LOG: " << name;
}
on_foo(...) { log_event("foo"); }
on_bar(...) { log_event("bar"); }
... tedious but you only have to do it once.
};
class real_handler1 : public log_handler {
// any methods not
overridden will be logged.
}
class real_handler2 : public log_handler {
// any methods not overridden will be logged.
}
There are a lot of different ways you might want to chain or compose
handlers - inheritance, pointer chaining, handler trees etc. etc. All
can be achieved by "helper" handlers without changing the core proton
API. Probably once we establish the most common patterns we can ship
some templates to reduce the boilerplate code.
That will probably be a pattern for adding functionality to the
library: rather than adding options to the core API, provide base or
delegating handler classes. That makes it easy to swap the optional
features in and out without cluttering the core.
> On Fri, Apr 15, 2016 at 10:13 PM, Andrew Stitcher
> <astitc...@redhat.com>
> wrote:
>
> >
> > On Fri, 2016-04-15 at 19:29 +0200, Alexandre Trufanow wrote:
> > >
> > > The changes look good overall, removing the event class makes the
> > > handler's
> > > API much cleaner IMO.
> > > I found the on_unhandled callback very useful for
> > > testing/debugging,
> > > when I
> > > didn't know what event to expect for my unit tests. Do you think
> > > there
> > > could be another way of setting a catchall for events?
> > We considered this when deciding to remove on_unhandled - the
> > problem
> > is that after removing event there was no way to make on_unhandled
> > at
> > all useful.
> >
> > So we'd need some other way to handle this, a possibility would be
> > to
> > add logging to the empty default handlers, which logs that the
> > specific
> > handler hasn't been called but not overridden. As the C++ library
> > has
> > no logging infrastructure at the moment, we'd have to add this
> > first.
> >
> > Note though that in many applications you will expect to call empty
> > handlers a lot, so that logging every unhandled event might be
> > overkill.
> >
> > I agree with Justin that it will be very useful to log the events
> > at
> > source in any case.
> >
> > Andrew
> >
> >
> > -----------------------------------------------------------------
> > ----
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
