Enable/disable event logging at runtime (Java client)

[Paul Hoadley]

Hello,

I am using the Java client for event logging from a web application. At the application level, I want to be able to enable or disable Keen IO logging via a runtime property. For example, in development, I don't always want logging to go to even a development project. But I only want to check this property once on application startup. At the moment, if it's set to "true", I set up a simple client and call KeenClient.initialize(client).  If false, I'm doing nothing, but then later calling, say, addEventAsync() throws an exception because KeenClient is not initialized.  I'd rather not have to guard each of these calls with a check of the property—it would be great if it was like, say, Log4J where you just throw whatever you want at the Logger, and it's the central log level setting that determines if that results in anything.

I see the method KeenClient.setActive(), but it's protected so it wouldn't seem to be of use here. Is there an idiom for creating a "null client" to solve this kind of problem?  Do I have to subclass KeenClient?

-- 

Paul Hoadley

http://logicsquad.net/

[Josh Dzielak]

Thanks for posting Paul.

Noodled on this a bit. Thoughts:

1) It would be great to have a SLF or Log4j bridge that lets Keen be an output source. Then we could take advantage of familiar log level and configuration semantics. Side project anyone? :)

2) In the meantime, I'm inclined to vote for adding a null/mock client implementation. I think that pattern is a bit cleaner, more configurable, and harder to abuse than a full-blown on/off switch.

Thoughts?

[Paul Hoadley]

Hi Josh,

On Wednesday, December 10, 2014 12:47:47 PM UTC+10:30, Josh Dzielak wrote:

2) In the meantime, I'm inclined to vote for adding a null/mock client implementation. I think that pattern is a bit cleaner, more configurable, and harder to abuse than a full-blown on/off switch.

Thoughts?

I'm not at all familiar with the source, but would making KeenClient.setActive(boolean) public (it's protected) not achieve this? Or would that have other side-effects? (I'm really just going by the name of the method and its Javadoc comments, so I could be way off.)

[Kevin Litwack]

Hi Paul,

The setActive method is currently being used to handle initialization errors, such as if the HttpHandler or KeenJsonHandler interfaces aren't provided or aren't initialized properly. The idea (at least when I designed it) was to protect against a bad initialization causing the KeenClient to thrash constantly. (The merits of that design are debatable, but that's a separate conversation.) We *could* expose setActive publicly, but I worry about making sure the behavior is robust and predictable. For example, what if the client is activated/deactivated multiple times, concurrently with various queueEvent and sendQueuedEvents calls?

I think I'm inclined to agree with Josh that a null client whose behavior is constant sounds a little safer. I think you could actually get this behavior today by using (for example) JavaKeenClientBuilder.withJsonHandler(null).build(). That's a bit hacky, but it shouldn't be hard for us to provide an explicit NullKeenClientBuilder that did something a little cleaner but with the same net result. Another way of thinking of it is exposing active/inactive at construction time rather than at use time.

What do you guys think?

Kevin

[Paul Hoadley]

Hi Kevin,

On Thursday, December 11, 2014 3:47:55 PM UTC+10:30, Kevin Litwack wrote:

We *could* expose setActive publicly, but I worry about making sure the behavior is robust and predictable.

Yeah, understood. I was only guessing—I thought my use case may not be that method's intended use.

I think I'm inclined to agree with Josh that a null client whose behavior is constant sounds a little safer. I think you could actually get this behavior today by using (for example) JavaKeenClientBuilder.withJsonHandler(null).build(). That's a bit hacky, but it shouldn't be hard for us to provide an explicit NullKeenClientBuilder that did something a little cleaner but with the same net result. Another way of thinking of it is exposing active/inactive at construction time rather than at use time.

What do you guys think?

Sounds good to me. I might try that hack in the meantime.

[Josh Dzielak]

Ok great. Kevin and I can think about the null client pattern. In the meantime let us know if that hack works.

Thanks!

[Paul Hoadley]

Hi guys,

On Friday, December 12, 2014 5:29:39 AM UTC+10:30, Josh Dzielak wrote:

Ok great. Kevin and I can think about the null client pattern. In the meantime let us know if that hack works.

It works just fine. Thanks for your help.

[Josh Dzielak]

Great. Thanks Paul!