We’re excited to announce another release of the Snowplow Java Tracker version 0.5.0
This release comes with a few changes to the Tracker method signatures to support our upcoming Snowplow 0.9.7 release with POST support, bug fixes, and more. Notably, we’ve added a new class for supporting your context data.
I’ll be covering everything mentioned above in more detail:
- Project structure changes
- Collector endpoint changes for POST requests
- The SchemaPayload Class
- Emitter callback
- Configuring the buffer
- Tracker context bug fix
We have changed the project structure so that the Java Tracker is now java-tracker-core as a subproject of the root
snowplow-java-tracker project. The structure looks something like this:
This is part of a re-structuring to make space for a
java-tracker-server that we’re looking to add in the future, and to allow code re-use with the Snowplow Android Tracker, which is coming soon. What this means for you, is that some enum classes have been moved from the
com.snowplowanalytics.snowplow.tracker package to
com.snowplowanalytics.snowplow.tracker.core. If you’re pulling the tracker straight from GitHub and you come across any caching warnings, try removing your current Tracker project and do a clean pull.
We decided to make a change to the collector endpoint for POST requests, so that the URI path would follow the format
/[api_vendor]/[api_version]. This is similar to how we append
/i to the collector endpoint. So an example of what the URI would look would be:
If requests are being sent as GET, we default to appending the original
/i to the end of the collector URI.
A new class
SchemaPayload has been added as a wrapper around your custom contexts. The idea is to make sure that each context is a valid self-describing JSON which Snowplow can process. Hence, a
SchemaPayload instance provides two methods
setData. Here’s an example if your context was a simple map:
What this ends up looking like in a JSON format, note the
The new class also changes the track methods from accepting a context of
List<SchemaPayload>. Here’s an example of the new method signatures:
The Emitter class now supports callbacks for success/failure of sending events. If events fail to send, you can now choose how to handle that failure, by passing in a class using the
RequestCallback interface to the
Emitter object. Here’s an example to make it easier to understand:
If events are all successfully sent, the
onSuccess method returns the number of successful events sent. If there were any failures, the
onFailure method returns the successful events sent (if any) and a list of events that failed to be sent (i.e. the HTTP state code did not return 200).
We’ve also added two new Emitter constructors to support callbacks:
This is an optional feature, so if you choose to not worry about the failed events, you can still use the original
We’ve changed the default behavior of sending events in this update. When you create an
Emitter and set the
HttpMethod to send GET requests, we default the Emitter to send events instantly upon being tracked. It makes most sense to send GET requests immediately since they cannot be grouped like events sent via POST.
Here is a short example:
There was a bug in our tracking method signatures whereby the context argument was passed as a
Map. We have now fixed this: all signatures expect a
List of contexts, using the new
SchemaPayload as mentioned above. The new type for passing the context is
We have made a few miscellaneous fixes in this version, including:
- We have added some unit tests for the
- Base64 encoding of unstructured event and context JSONs now uses
For more details on this release, please check out the 0.5.0 Release Notes on GitHub.