the class PiwikDate renders the date in a 12-hours format without the AM/PM indication, as a result all actions are logged in the morning!

Changing the following line in both constructors for the PiwikDate class fixes the issue

format = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss");
into
format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

Thank you!
Andrea

Log4J 2.11 is vulnerable for these CVE's:
CVE-2021-44228(10.0), CVE-2021-45046(9.0)
Upgrading to the most recent Log4J version will fix this.
Using tools like OWASP Dependency check or Dependabot make it easy to detect and fix these and similar issues.
I will create a pull-request if I have time to upgrade this and any other dependencies that are out-dated.
Depending on the effectiveness of your test-suite, this should easily fix this.

Hi,

I tried to integrate the library using jitpack.io which fails (https://jitpack.io/com/github/piwik/piwik-java-tracker/709012c/build.log). I assume this is because Java 1.8 features are used (e.g. map.putIfAbsent for Map in CustomVariableList) but the POM sets Java 1.7 as the target version.

Could you look into this? Thanks

Kind regards...

ACTION_URL and DOWNLOAD_URL are defined as java.net.URL.URL objects in the getters and setters.
I think they should be set and get as strings in order to accept more protocols than the ones supported by the URL class.
This for example would allow tracking of RTMP URLs.

TODO: verify if Piwik accepts RTMP and other non-HTTP protocols!

Thank you,
Andrea

Hi guys!
Is there any way to ignore SSL validation using the PiwikTracker?
I want to disable to test this in my Test Environment but getting the following expectation:
javax.net.ssl.SSLPeerUnverifiedException: Hostname does not match the certificate subject provided by the peer

TBD

Hi there,

this issue refs matomo-org/matomo#16397 (comment)

in Matomo 4 we're changing the structure of the visitor cookie. I don't know if this SDK reads the cookie of a visitor if one is set?

In the PHP tracker we had to make this change because of it https://github.com/matomo-org/matomo-php-tracker/pull/79/files#diff-cd22a4ca6eb55e6a5ad813334624ed89L1370-L1840

The cookie was changed in https://github.com/matomo-org/matomo/pull/15774/files#diff-1279d666063b65e6d6777f902d11574fR3322-R3330

It used to contain 6 indexes (newVisitor, uuid, createTs, visitCount, currentVisitTs, lastVisitTs) but now contains only indexes:
Slot 0: newVisitor
Slot 1: uuid
Slot 2: createTs

Basically, if this tracker does read the cookie, then the tracker needs to be changed to only read the first to slots from the cookie (cookieVisitorId and createTs) see https://github.com/matomo-org/matomo-php-tracker/pull/79/files#diff-cd22a4ca6eb55e6a5ad813334624ed89L1370-L1840

All other information from the cookie list visit count, currentVisitTs, lastVisitTs is no longer needed in Matomo 4.

If this tracker does not read any cookies then it can be ignored.

Describe the bug
Inside MatomoRequest class, eventValue duplicated the param name for eventName, both showing e_n

Code snippets

    @TrackingParameter(
        name = "e_n"
    )
    private String eventName;
    @TrackingParameter(
        name = "e_n"
    )
    private Double eventValue;

Expected behavior
eventValue name should be e_v as mentioned in docs:

Optional Event Tracking info

e_c — The event category. Must not be empty. (eg. Videos, Music, Games...)
e_a — The event action. Must not be empty. (eg. Play, Pause, Duration, Add Playlist, Downloaded, Clicked...)
e_n — The event name. (eg. a Movie name, or Song name, or File name...)
e_v — The event value. Must be a float or integer value (numeric), not a string.

Additional context
Add any other context about the problem here.

Hi,

when trying to send a PiwikRequest that contains an EcommerceItem a ClassCastException is thrown by the org.glassfish.json.JsonGeneratorImpl.write method since EcommerceItem cannot be cast to javax.json.JsonArray. See stack trace below.

java.lang.ClassCastException: org.piwik.java.tracking.EcommerceItem cannot be cast to javax.json.JsonArray
    at org.glassfish.json.JsonGeneratorImpl.write(JsonGeneratorImpl.java:275)
    at org.glassfish.json.JsonWriterImpl.writeArray(JsonWriterImpl.java:102)
    at org.glassfish.json.JsonWriterImpl.write(JsonWriterImpl.java:141)
    at org.glassfish.json.JsonArrayBuilderImpl$JsonArrayImpl.toString(JsonArrayBuilderImpl.java:266)
    at org.piwik.java.tracking.PiwikJsonArray.toString(PiwikJsonArray.java:61)
    at org.piwik.java.tracking.PiwikRequest.getUrlEncodedQueryString(PiwikRequest.java:1469)
    at org.piwik.java.tracking.PiwikTracker.sendRequest(PiwikTracker.java:49)
    ...

Test code that creates the error:

PiwikRequest request = new PiwikRequest(3, new URL("http://test-app.com/"));
request.enableEcommerce();
request.setEcommerceId(UUID.randomUUID().toString());
request.setEcommerceRevenue(5.99);
EcommerceItem item = new EcommerceItem("cashbundle.l", "Cash Bundle L", "Consumable", 5.99, 1);
request.addEcommerceItem(item);
PiwikTracker tracker = new PiwikTracker("http://my-tracking-server.com/piwik.php");
HttpResponse response = tracker.sendRequest(request);

The piwik-java-tracker library and its dependencies are included using maven:

<dependency>
    <groupId>org.piwik.java.tracking</groupId>
    <artifactId>piwik-java-tracker</artifactId>
    <version>1.0.1</version>
</dependency>

Any advice?

Since upgrading to 3.13 all of the sessions where a user id was set get a new visit created for each action.

I'm using the piwik_java_tracker and looking at the code it puts a new random string the the visitor id of each request. This has worked fine in the past, both when a user id was set and when one was not set.

As a workaround: explicitly setting the visitor id to a hex value derived from the user id whenever a userid is set seems to do the trick.

But ideally it should just follow the same logic as the scenario without a user id. There as well, a unique visitor id is created for each request by the piwik_java_tracker but at least the server side is able to group all actions into one session.

See also matomo-org/matomo#15299

We use the latest version of this library:

        <dependency>
            <groupId>org.piwik.java.tracking</groupId>
            <artifactId>matomo-java-tracker</artifactId>
            <version>1.5</version>
        </dependency> 

Because of a deprecated message we changed the PiwikTracker.sendRequest() to the asynchronous version PiwikTracker.sendRequestAsync().

After a deployment at the live systems we noticed a large consumption of threads: The number of threads grow on every page request by the number of CPUs + 1!
After a longer research we found the reason within your sendRequestAsync() implementation: This method creates a new AsyncHttpClient each time. As a consequence a new threadpool is created.

Please note that the documentation of AHC clearly defines that this kind of client should be a singleton / should be shared within the application:

AsyncHttpClient instances are intended to be global resources that share the same lifecycle as the application. Typically, AHC will usually underperform if you create a new client for each request, as it will create new threads and connection pools for each. It's possible to create shared resources (EventLoop and Timer) beforehand and pass them to multiple client instances in the config. You'll then be responsible for closing those shared resources.

We changed our code back for using the synchronous version to fix the problem by now.

Suggested solutions:

• Share the client by using a singleton. In this case we do not need to change the code.
• Create the client once in PiwikTracker. In this case we will change the code to use PiwikTracker as a singleton.

Are the following http://developer.piwik.org/api-reference/reporting-api#SitesManager implemented in the Java version of the API?

Currently, in the MatomoRequest Java class, users need to manually set the goalId parameter. However, if any ecommerce parameter is set without updating the goalId accordingly, it results in an exception on validation. To prevent such mistakes and enhance user experience, this enhancement request proposes automatic setting of the goalId to 0 when any ecommerce parameter is detected.

Expected Behavior

When any ecommerce parameter (ecommerceRevenue, ecommerceItems, ecommerceSubtotal, ecommerceTax, ecommerceShippingCost, ecommerceDiscount, ecommerceLastOrderTimestamp) is set, the MatomoRequest class should automatically set the goalId to 0.

Use Case

This enhancement is essential for scenarios where ecommerce data is being tracked. Automatic adjustment of the goalId ensures consistent and accurate representation of data in analytics.

Implementation Suggestion

Add a conditional check in the MatomoRequest class to automatically detect the presence of any ecommerce-related parameters. If such parameters are present, set the goalId to 0.

Additional Information

• This enhancement aligns with best practices in analytics tracking when dealing with ecommerce data.
• Ensures a smoother user experience by eliminating the need for manual intervention in setting goalId in ecommerce scenarios.

Acceptance Criteria

• When any ecommerce parameter is set, the goalId should be automatically set to 0.
• The modification should not interfere with existing functionality and should be backward compatible.

It seems not possible to track referers not using http/https, like android-app urls. Unfortunately PiwikRequest.setReferrerUrl(...) expects an URL so it's not possible to track them, unless URLStreamHandler is used for every scheme, in theory. Not sure how that will work out, I am currently in the process of trying it out.

It wouldn't be much of an issue if it weren't for the fact that we got quite some requests using that referrer and feels like we are missing important analytic data. See Sentry screenshot below:

Has anybody dealt with that already?

Description:
Currently, our Matomo Java Tracker lacks the ability to dynamically read the remote user attribute from an HttpServletRequest in Java and set the user id attribute in the Matomo request accordingly. This feature would significantly enhance our tracking capabilities and provide more accurate user insights.

Steps to Reproduce:

1. Deploy the current version of the Matomo integration.
2. Observe the lack of functionality to dynamically read the remote user attribute.
3. Identify scenarios where remote user attribute information is crucial for tracking.

Expected Behavior:
The Matomo integration should be extended to retrieve the remote user attribute from the HttpServletRequest in Java and use it to set the user id attribute in the Matomo request.

Additional Context:
This enhancement is essential for improving the accuracy of user tracking, especially in scenarios where users are authenticated remotely.

Proposed Solution:

1. Create a method in the Matomo integration to extract the remote user attribute from the HttpServletRequest.
2. Set the user id attribute in the Matomo request based on the retrieved remote user attribute.

BulkRequest is not performing a request. I have sent Iterable<PiwikRequest> list to new PiwikTracker(matomoSeverUrl).sendBulkRequest(requests); and I got 200 status code, but actually no data is sent to Matomo server.

Here is the example:

`

    import org.apache.http.HttpResponse;
    import org.piwik.java.tracking.PiwikRequest;
    import org.piwik.java.tracking.PiwikTracker;
    import org.slf4j.Logger;
    import org.slf4j.LoggerFactory;
    
    import java.io.IOException;
    import java.net.URL;
    import java.util.ArrayList;
    import java.util.Collections;
    import java.util.List;
    
    public class Example {
    
        private static final Logger LOGGER = LoggerFactory.getLogger(Example.class);
    
        final String matomoTrackingUrl = "MATOMO_SERVER_URL";
        final int matomoSiteId = 1;
        
        public void sendToMatomo(final ObjectEntity objectEntity) {
            makeRequest(buildRequest(objectEntity), null);
        }
        
        public void sendToMatomoBulk(final List<ObjectEntity> statusLogEntities) {
            final List<PiwikRequest> piwikRequests = new ArrayList<>();
    
            statusLogEntities.forEach(objectEntity -> {piwikRequests.add(buildRequest(objectEntity));});
    
            piwikRequests.removeAll(Collections.singleton(null));
            makeRequest(null, piwikRequests);
        }
    
        private void makeRequest(final PiwikRequest piwikRequest, final Iterable<PiwikRequest> piwikRequests) {
            try {
                final PiwikTracker tracker = new PiwikTracker(matomoTrackingUrl);
                HttpResponse httpResponse = null;
    
                if (piwikRequest != null) {
                    httpResponse = tracker.sendRequest(piwikRequest);
                }
    
                if (piwikRequests != null) {
                    httpResponse = tracker.sendBulkRequest(piwikRequests);
                }
    
                if ((httpResponse != null) && (httpResponse.getStatusLine().getStatusCode() != 200) &&
                        (httpResponse.getStatusLine().getStatusCode() != 204)) {
                    LOGGER.error("Request to Matomo server failed with status code: " +
                            httpResponse.getStatusLine().getStatusCode() + " and reason phrase: " +
                            httpResponse.getStatusLine().getReasonPhrase());
                }
            } catch (final IOException e) {
                LOGGER.error("Cannot send a request to Matomo Server.", e);
            }
        }
    
        private PiwikRequest buildRequest(final ObjectEntity objectEntity) {
            try {
                final URL actionUrl = new URL(matomoTrackingUrl);
    
                final PiwikRequest request = new PiwikRequest(matomoSiteId, actionUrl);
                
                // .. other settings
    
                return request;
            } catch (final IOException e) {
                LOGGER.error("Cannot build a request for the given status log entity.", e);
            }
    
            return null;
        }
    }

`

I have made a single request by iterating the list and it works well. Could you please confirm if this is bug ? or did I have something wrong?

Thank you.

While dependencies are included with this project, it's often unwieldy for users of this tracker to include lots of libraries. This also increases the potential that a user may miss a dependency.

Publishing this project to the Maven central repository would resolve this issue and provide a cleaner way to download and include this tracker in projects.

Presently, the Matomo Java Tracker library does not enforce the Matomo instance's limitation of five custom variables per request and 100 characters per key and value field. To align with Matomo's specifications, we need to implement a check within the library to ensure that no more than five custom variables and 100 characters are added in a single request.

Expected Behavior:
Upon attempting to add a sixth custom variable in a single request, the system should throw a MatomoException to indicate that the Matomo instance only supports up to five custom variables and 100 characters per request.

Steps to Reproduce:

1. Add five custom variables using the Matomo Java Tracker library in a single request.
2. Attempt to add another custom variable within the same request.
3. Add a custom variable with a key that is longer than 100 characters.

Actual Result:
The library allows the addition of the sixth custom variable without adhering to Matomo's restriction, potentially causing discrepancies.

Expected Result:
The system should throw a MatomoException when attempting to add a custom variable beyond the Matomo instance's limit of five per request.

Additional Information:

• Matomo Java Tracker Library Version: 3.1.1
• Matomo Instance Version: 4

Note:
By implementing this check, we aim to ensure that the Matomo Java Tracker library aligns with Matomo's specifications, preventing unintended behavior and maintaining compatibility with Matomo instances enforcing the custom variables limit.

Currently, the Matomo Java Tracker application allows for the same query parameter to be added multiple times using the additionalParameters method. However, this behavior is not consistent with the Matomo Tracking HTTP API, as it allows only one occurrence of a parameter.

Proposed Solution:

Modify the Matomo Java Tracker code to enforce a singular occurrence of each parameter in the URL when using the additionalParameters method. This adjustment aligns with common URL parameter practices and helps prevent potential confusion or unexpected behavior.

Additional Information:

1. Current Behavior:
   The additionalParameters method allows the same parameter name to be added multiple times, resulting in duplicate parameters in the URL.

2. Proposed Behavior:
   Update the code to ensure that only one occurrence of each parameter is allowed in the URL when using the additionalParameters method.

3. Rationale:
   Having multiple occurrences of the same parameter in a URL can lead to confusion and is not a standard practice. The proposed modification aims to enhance consistency and adherence to established conventions.

Steps to Reproduce:

1. Use the additionalParameters method to add the same parameter multiple times.
2. Note the resulting URL with duplicate parameters.

Expected Result:
The Matomo Java Tracker should restrict the addition of duplicate parameters, ensuring only one occurrence of each parameter in the generated URL.

Additional Comments:
This change will improve the overall usability and conformity of the Matomo Java Tracker, aligning it with widely accepted URL parameter practices.

I had some trouble using this library in my companies project, due to overlapping and conflicting dependencies. Please consider scoping maven dependencies appropriately.
(i.e I guess Mockito is only used for testing etc.)

For now I solved my issues by shading your artifact and hiding the transitive dependencies.

TBD

Describe the bug
We recently updated to version 3 of the matomo-java-tracker library and have started having issues with resources being exhausted. We are sending a server side event to matomo when one of our API endpoints is accessed. Initially we were using the jre8 jar before we realized there was a separate jre11 version, but we are still experiencing the issue after switching. It seems to cause our server to run out of resources and require a restart periodically. The error looks like:

java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
        at java.base/java.lang.Thread.start0(Native Method)
        at java.base/java.lang.Thread.start(Thread.java:798)
        at java.net.http/jdk.internal.net.http.HttpClientImpl.start(HttpClientImpl.java:320)
        at java.net.http/jdk.internal.net.http.HttpClientImpl.create(HttpClientImpl.java:254)
        at java.net.http/jdk.internal.net.http.HttpClientBuilderImpl.build(HttpClientBuilderImpl.java:135)
        at org.matomo.java.tracking.Java11SenderProvider.provideSender(Java11SenderProvider.java:57)
        at org.matomo.java.tracking.ServiceLoaderSenderFactory.createSender(ServiceLoaderSenderFactory.java:25)
        at org.matomo.java.tracking.MatomoTracker.initializeSender(MatomoTracker.java:155)
        at org.matomo.java.tracking.MatomoTracker.sendRequestAsync(MatomoTracker.java:197)
        at org.matomo.java.tracking.MatomoTracker.sendRequestAsync(MatomoTracker.java:172)
        at edu.unc.lib.boxc.web.common.utils.AnalyticsTrackerUtil.sendMatomoRequest(AnalyticsTrackerUtil.java:89)
        at edu.unc.lib.boxc.web.common.utils.AnalyticsTrackerUtil.trackEvent(AnalyticsTrackerUtil.java:60)
        at edu.unc.lib.boxc.web.access.controllers.FedoraContentController.recordDownloadEvent(FedoraContentController.java:127)
        at edu.unc.lib.boxc.web.access.controllers.FedoraContentController.streamData(FedoraContentController.java:101)
        at edu.unc.lib.boxc.web.access.controllers.FedoraContentController.getDefaultDatastream(FedoraContentController.java:64)

Code snippets
Our code that triggers the events is found here:
https://github.com/UNC-Libraries/box-c/blob/v5.31.2/web-common/src/main/java/edu/unc/lib/boxc/web/common/utils/AnalyticsTrackerUtil.java#L67-L93
Which is very similar to our usage prior to matomo-java-tracker v3:
https://github.com/UNC-Libraries/box-c/pull/1655/files

Expected behavior
Sending events should not cause our application to stop working.

Additional context
It seems like the resource exhaustion started happening shortly after we made adjustments to how the visitorId was being set since we were getting many of the following errors:

java.lang.NullPointerException: inputHex is marked non-null but is null
	at org.matomo.java.tracking.parameters.VisitorId.fromHex(VisitorId.java:87)
	at edu.unc.lib.boxc.web.common.utils.AnalyticsTrackerUtil.buildMatomoRequest(AnalyticsTrackerUtil.java:70)

Which was being triggered by bot traffic when "Proxy-Client-IP: 0.0.0.0" was set, which caused us to pass a null visitorId to matomo. We changed it to passing in a randomly generated visitorId, which resolved the inputHex is marked non-null but is null error, but no resources are being exhausted instead, possibly because many more requests are being sent to matomo.

I'm trying to replicate the issue on our testing servers but haven't been able to do so yet, but we've had it happen in production twice in a week.

We have not changed the default threadPoolSize or any of the timeouts, but it seems like increasing the number might make it exhaust all threads sooner?

Feature Description

Currently, the Matomo Java Tracker sends each tracking request to the Matomo server as soon as it is created. This can lead to a large number of individual requests being sent to the server, especially in high-traffic applications.

I propose adding a feature that allows the tracker to collect multiple tracking requests over a certain delay period and then send them all at once in a bulk request. This could potentially reduce the load on the Matomo server and improve the performance of the tracker.

Proposed Implementation

The tracker could have a configurable delay period (for example, 5 seconds) during which it collects all created tracking requests. At the end of this delay period, it sends all collected requests to the Matomo server in a single bulk request.

This feature could be optional and controlled by a new configuration property (for example, matomo.tracker.bulk-collection-delay). If this property is not set or set to 0, the tracker operates as it currently does, sending each request immediately.

Potential Challenges

One challenge could be ensuring that the tracker correctly handles the case where a new tracking request is created while it is in the middle of sending a bulk request. We would need to make sure that this new request is either included in the current bulk request (if possible) or held for the next bulk request.

Another challenge could be error handling for the bulk request. If the Matomo server returns an error for the bulk request, we would need a way to determine which individual request(s) caused the error.

Impact

This feature could significantly reduce the number of requests that the tracker sends to the Matomo server, potentially improving performance for both the tracker and the server. It could be particularly beneficial for high-traffic applications that generate a large number of tracking requests.

See matomo-org/matomo#16569 to learn more about the problem it fixes and visit https://developer.matomo.org/api-reference/tracking-api for more documentation about the new ca parameter.
Basically, we should be sending &ca=1 along any tracking request that isn't a page view. Practically, we should for now only send &ca=1 along any event and content tracking requests.

The parameter isn't required but it helps for more accurate tracking for edge cases where a user suddenly disables eg an event, goal or ecommerce plugin but still keeps sending these requests. If the parameter is not sent, Matomo would turn the tracking request into a page view and track a page view even though the tracking request should be ignored.

Let me know if there are any questions about this.

The code is quite dated and in need of TLC. Including it in my project causes errors due to old libraries.

I could fix the old libraries and add org.apache.http.impl.nio.client.HttpAsyncClientBuilder but why bother if PiwikRequest is not maintained to accomodae the latest functionality of Matomo?

Is PiwikRequest up to date with respect to Matomo 3.8.0?

We perform the releases manually on our developer machines. These builds are not reproducible and require a specific setup.

As a solution we would like to use GitHub Action. The workflow already exists, but we have to add the necessary secrets to it:

• GPG_PRIVATE_KEY
• OSSRH_USERNAME
• OSSRH_PASSWORD
• GPG_PASSPHRASE
• GITHUB_TOKEN

Hi @tholu!

I did a complete rewrite of the library just for fun: https://github.com/dheid/matomo-tracker

It does not have any dependencies, has less code and is easier to maintain. There is no benchmark, but it could be a little bit faster / less memory consuming.

Perhaps we can think about merging the two projects together? I don't know if the users of your library will like this.

What do you think?

Is your feature request related to a problem? Please describe.
Your pom.xml files of release 3.2.0 an earlier contain the version number of the next development snapshot like this: <version>3.2.1-SNAPSHOT</version>

Describe the solution you'd like
Released pom.xml files should contain the correct version number: 3.2.0. Example: https://github.com/jetty/jetty.project release 12.0.5 pom.xml files contain <version>12.0.5</version>

Describe alternatives you've considered
n/a

Additional context
When I build the current release, my built JAR files are named 3.2.1-SNAPSHOT. Mavens .m2 repository cache contains Matomo dirs named 3.2.1-SNAPSHOT. It's very confusing, which version is built.

I cannot get PiwikTracker to work, when I instantiate a PiwikTracker object it hangs on new PiwikTracker()

I pass my piwik API endpoint as a String object like "http://piwik.myorganization.com/piwik.php" but it does not return and it does not throw any Exception.

I have the following in my classpath
javax.json-1.0.4.jar
javax.ws.rs-api-2.0.1.jar
jersey-common-2.23.1.jar

(downloaded by hand from maven.apache.org)

Any hint at what I am doing wrong?
Thank you very much!
Andrea

The Request builder first sets the search category and then the search query. This leads to this error.

Issue

For some reason, the events are not showing in the Event list inside Behaviour section, but I can see them on the Visitors Log

Here you can see the list of actions with 6 actions

Here you can see the events has only 3 entries

Your Environment

• Matomo Version: 4.1.1
• Matomo Tracker Java Library: 1.5
• PHP Version: 7.4.15
• Operating System: Ubuntu

The current release script for our project lacks an essential step to keep the version information consistent across our documentation. Specifically, we need to update the versions in the Maven XML and Gradle Groovy snippets within the README.md file with the latest version from the Maven POM.

Proposed Solution:
Integrate a GitHub Actions step into the release script that automatically fetches the latest version from the Maven POM and updates the corresponding sections in README.md. It's crucial that this process doesn't rely on version placeholders but instead overwrites the existing version, commits the change, and pushes it during the execution of the release Workflow.

Steps to Reproduce:

1. Trigger the release Workflow.
2. Observe the README.md file for updated version information in Maven XML and Gradle Groovy snippets.

Expected Outcome:
The README.md file should reflect the latest version from the Maven POM after the release Workflow completes.

Additional Information:
Ensure that the script is well-documented and adheres to best practices. This enhancement will streamline version management across our documentation and build files, minimizing the risk of inconsistencies.

Using MatomoTracker#sendRequestAsync method there is no easy way for caller to know if the call succeeds other than calling response.get(...) that causes calling thread to block and makes it effectivelly same as sendRequest .

Consider allowing clients to pass callback to HttpAsyncClient execute from MatomoTracker#sendRequestAsync et. al.

Is there a version that uses asynchronous and safe thread sending?
Now it looks like sending any request will be blocking the whole application.

This library has a huge potential to be used by Piwik community. To let everyone know that the tracker SDK is available, it will be ideal to publish a blog post on our blog.

Would you mind drafting a short blog post about the library?

Ideally the blog post would:

• introduce the possibilities of the Java SDK
• list the requirements
• getting started: download, quick setup or link to setup Readme
• small snippets of tracking page views, an event...
• Contribute section: we welcome bug reports and pull requests

Here is the example for iOS SDK:
https://piwik.org/blog/2013/10/mobile-analytics-sdk-beta-release-of-piwik-ios-sdk/

Or for C#:
https://piwik.org/blog/2013/02/c-sharp-tracking-and-analytics-api/

What do you think @bcsorba ?

Users are currently able to only add custom variables and as such are unable to specify an index for a custom variable. This prevents users from actively setting the index of their custom variables and makes it impossible for users to send a custom variable at a given index unless they've specified custom variables for all indexes before that given index.

Plan to deprecate the current getters and setters for page a user custom variables and allow users to get and set a new CustomVariable object at a specified index.

I am sending events using Piwik Tracker with the sendBulkRequestAsync method, and the event is appearing as Custom Variable in the dashboard. It should appear in the events list.

{
"eventName":"Name: ",
"eventAction":"Action",
"eventCategory":"Category",
"eventValue":null,
"eventTime":1655388962709
}

Events are being raised from Spring Boot Java using Piwik Tracker.
Dependency Used:

org.piwik.java.tracking
matomo-java-tracker
1.7

Unordered user custom variables in piwik.piwik_log_visit table due to PiwikJsonObject class has field map implementation HashMap instead of LinkedHashMap.
Would you be kind enough to fix it?

Piwik plugins may allow for custom tracking parameters. Users should be able to set these in a PiwikRequest through

request.setCustomTrackingParameter(key, value);

To support Matomo's new Crash Analytics feature, we'd like to add crash tracking methods in all supported tracking SDKs.

The tracking methods should be similar to the PHP SDK's methods:

public function trackPhpThrowable(\Throwable $ex, $category = false); // deduces as much information as possible

public function trackCrash($message, $type, $category, $stack, $location, $line, $column); // user supplies all information

trackCrash() passes its parameters as the following HTTP API parameters:

• $message: sent as cra, the crash message
• $type: sent as cra_tp, the type of crash, for example "TypeError"
• $category: sent as cra_ct (optional, it's like a custom dimension to categorise the crash, typically left empty)
• $stack: sent as cra_st, a stack trace or similar
• $location: (the originating source file) sent as cra_ru, the file name or source or something similar
• $line: sent as cra_rl, the line number in the file
• $column: sent as cra_rc, the column within the line of the file

IMPORTANT It must also pass ca=1 (stands for 'custom action') as a parameter so if the plugin is deactivated in Matomo, nothing will be tracked.

trackPhpThrowable (or the equivalent method for the language of this SDK) should accept an exception object and deduce set the crash tracking parameters based on it. The type should be set to the exception class name or something similar.

See also the implementation in the PHP tracker:

• https://github.com/matomo-org/matomo-php-tracker/blob/master/MatomoTracker.php#L937-L966
• https://github.com/matomo-org/matomo-php-tracker/blob/master/MatomoTracker.php#L1323-L1347

Please let me know if there are any questions.

As a developer utilizing the Matomo Java Tracker in my application, I find it crucial to expand its capabilities by incorporating tracking methods that align with the existing PHP functionality. The focus is on introducing Java counterparts for the following tracking methods:

• doTrackAction(actionUrl: string, actionType: string): mixed|string|true
• doTrackContentImpression(contentName: string, [contentPiece: string = 'Unknown'], [contentTarget: bool|string = false]): mixed|string|true
• doTrackContentInteraction(interaction: string, contentName: string, [contentPiece: string = 'Unknown'], [contentTarget: bool|string = false]): mixed|string|true
• doTrackCrash(message: string, [type: null|string = null], [category: null|string = null], [stack: null|string = null], [location: null|string = null], [line: int|null = null], [column: int|null = null]): mixed|string|true
• doTrackEcommerceCartUpdate(grandTotal: float): mixed|string|true
• doTrackEcommerceOrder(orderId: int|string, grandTotal: float, [subTotal: float = 0.0], [tax: float = 0.0], [shipping: float = 0.0], [discount: float = 0.0]): mixed|string|true
• doTrackEvent(category: string, action: string, [name: bool|string = false], [value: bool|float = false]): mixed|string|true
• doTrackGoal(idGoal: int, [revenue: float = 0.0]): mixed|string|true
• doTrackPageView(documentTitle: string): mixed|string|true
• doTrackPhpThrowable(ex: Throwable, [category: null|string = null]): mixed|string|true
• doTrackSiteSearch(keyword: string, [category: string = ''], [countResults: bool|int = false]): mixed|string|true

Usage

• Developers, like myself, should be able to seamlessly incorporate these methods into their Java applications for tracking relevant events within the Matomo environment.

Implementation Guidelines

• Ensure that the Java implementation mirrors the behavior of the corresponding PHP methods as documented in the MatomoTracker specifications.
• Perform thorough validation of input parameters and handle exceptions gracefully.
• Maintain compatibility with the existing Matomo Java Tracker structure and classes.

Testing

• Rigorous unit tests should be conducted to validate the accuracy and reliability of the implemented tracking methods.
• Integration tests can be performed in a controlled environment to verify the recorded data in the Matomo instance.

Documentation

• Update the Matomo Java Tracker documentation to include detailed information about the newly added tracking methods.
• Provide practical usage examples and any specific considerations for developers like myself.

Dependencies

• No additional dependencies should be added.

In matomo-org/matomo#9129 we created a new plugin to track Custom Dimensions.

To the JavaScript Tracker we added a new method setCustomDimension(int dimensionId, string dimensionValue). This sets a tracking API parameter dimension$dimensionId=$dimensionValue. Eg dimension1=foo or dimension2=bar. So the tracking API parameter starts with dimension followed by the set dimensionId.

I reckon we should be consistent here with the PHP Tracker and clear all set custom dimensions after the next tracking request was sent.
eg

setCustomDimension(1, 'myvalue1')
setCustomDimension(2, 'myvalue2)
trackPageview()
// now dimension 1 and 2 would be cleared and one has to set values again

FYI: Custom Dimensions are similar to Custom Variables. Currently a plugin is needed to use them but in Piwik 3.0 it will be installed by default and at some point we will deprecate Custom Variables (not soon though)

Hi @tholu @bcsorba - I've thought i'd go ahead and just renamed the project to matomo-java-tracker - the old url automatically redirects: https://github.com/matomo-org/piwik-java-tracker

Let me know if there's any problem or question.

also @tholu could you reach out at [email protected] or share your email address with us somehow? i wanted to share an info. Thanks

When using the async operations of the PiwikTracker the http client is never closed, but for every operation a new instance is created. This leads to a growing number of open file handles.

when I add the maven dependency

    <dependency>
        <groupId>org.piwik.java.tracking</groupId>
        <artifactId>piwik-java-tracker</artifactId>
        <version>1.2</version>
    </dependency>

to my Spring / RESTeasy app, I always get the error

java.lang.RuntimeException: RESTEASY013050: RESTeasy Provider Factory is null, do you have the ResteasyBootstrap listener configured?
	at org.jboss.resteasy.plugins.spring.SpringContextLoaderSupport.customizeContext```

any ideas how to fix that?

In the PiwikRequest class, the SITE_ID constant equals "idsite" instead of "idSite" thus I get this error in the response:
{ "result": "error", "message": "Merci de spécifier une valeur pour idSite" }