In my experience, releasing artifacts through maven central (via the Sonatype OSS process) is a slow process with multi-hour waits for artifacts to sync to mirrors. As a user, it would be nice to get new releases immediately when I'm eager to get a bug fix. Releasing on Bintray instead (which I have switching all of my projects) is much faster, and has other niceties as well (good CDN for distribution, etc). You can still have artifacts synced to maven central if you wish, or users can use the 'jcenter' repo, which is a superset of maven central, with the aforementioned CDN, etc.

If this sounds good, I'll make a PR.

I've integrated rollbar into a spring project and I'm using it to log errors that happens in @Async methods with this code:

    @Override
    public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() {
        return (ex, method, params) -> {
            String message = String.format("Error in async task of type %s:%s", method.getDeclaringClass(), method.getName());
            log.error("My Error while executing async method: {}", method.getName(), ex);
            rollbar.error(ex, message);
        };
    }

However the above code raises this rollbar error:

com.rollbar.utilities.ArgumentNullException: 'filename' cannot be null
	at com.rollbar.utilities.Validate.isNotNullOrWhitespace(Validate.java:20) ~[rollbar-utilities-0.5.4.jar:0.5.4]
	at com.rollbar.payload.data.body.Frame.<init>(Frame.java:65) ~[rollbar-payload-0.5.4.jar:0.5.4]
	at com.rollbar.payload.data.body.Frame.fromStackTraceElement(Frame.java:106) ~[rollbar-payload-0.5.4.jar:0.5.4]
	at com.rollbar.payload.data.body.Frame.fromThrowable(Frame.java:88) ~[rollbar-payload-0.5.4.jar:0.5.4]
	at com.rollbar.payload.data.body.Trace.fromThrowable(Trace.java:50) ~[rollbar-payload-0.5.4.jar:0.5.4]
	at com.rollbar.payload.data.body.Body.trace(Body.java:61) ~[rollbar-payload-0.5.4.jar:0.5.4]
	at com.rollbar.payload.data.body.Body.fromError(Body.java:49) ~[rollbar-payload-0.5.4.jar:0.5.4]
	at com.rollbar.Rollbar.buildPayload(Rollbar.java:517) ~[rollbar-0.5.4.jar:0.5.4]
	at com.rollbar.Rollbar.log(Rollbar.java:510) ~[rollbar-0.5.4.jar:0.5.4]
	at com.rollbar.Rollbar.error(Rollbar.java:266) ~[rollbar-0.5.4.jar:0.5.4]

Clients based on ahaid/rollbar-logback send "class_name" in the stack trace elements, e.g.:

          {
            "class_name": "java.lang.Thread", 
            "method": "run", 
            "lineno": 745, 
            "filename": "Thread.java"
          }, 
          {
            "class_name": "org.eclipse.jetty.util.thread.QueuedThreadPool$3", 
            "method": "run", 
            "lineno": 540, 
            "filename": "QueuedThreadPool.java"
          }, 
          {
            "class_name": "org.eclipse.jetty.util.thread.QueuedThreadPool", 
            "method": "runJob", 
            "lineno": 620, 
            "filename": "QueuedThreadPool.java"
          },

which results in a more java-like stacktrace on the UI:

128 at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob (QueuedThreadPool.java:620)
129 at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run (QueuedThreadPool.java:540)
130 at java.lang.Thread.run (Thread.java:745)

On the other hand this library does not support class_name and sends Frame objects without this field, which is rendered on the UI like this:

128 at runJob (org.eclipse.jetty.util.thread.QueuedThreadPool.java:620)
129 at run (org.eclipse.jetty.util.thread.QueuedThreadPool$3.java:540)
130 at main ( java.lang.Thread.java:745)

It's a bit odd given that the file names are incorrect (especially that ...$3.java)

Rollbar API spec does not mention class_name.

Could class_name be included (in the spec and in this client) to make stack traces in the UI look like regular java stacktraces - same as the ones from ahaid/rollbar-logback?

The problem @helderribeirosousa had in #72 is going to come up again for more users. Let's figure out some ways to make this issue, and other issues that manifest just as "it doesn't work", easier to debug and fix.

For the SSL cert issue in particular, we should add some documentation.

I expected to see an example of how to use the library at the top of the readme. I usually find the usage and installation to be the most important information for new users. People interested in contributing (like myself) will read further down the readme for information on how the project is structured and how we can contribute.

Do you have any preferences on what an example snippet should look like?

It l 8t 7g

The com.rollbar.Rollbar class suggests subclassing to allow for customizing things dynamically. This is clumsy in practice as it would be forced to rely on thread locals and the like. It would be easier to use if the context for a report could be provided per-call as an object.

Like all the other issues, happy to provide a PR.

Hello,

i rely on "rollbar 0.5.4" to gather errors on some production components and some internal errors fail to be sent due to, what seems to me, are validations that don't cover all valid scenarios.

Here's the stacktrace of the throwable object that should be sent to rollbar:

ThrownException: Exception Message at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:135) at com.sun.xml.internal.ws.client.sei.StubHandler.readResponse(StubHandler.java:238) at com.sun.xml.internal.ws.db.DatabindingImpl.deserializeResponse(DatabindingImpl.java:189) at com.sun.xml.internal.ws.db.DatabindingImpl.deserializeResponse(DatabindingImpl.java:276) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:104) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:77) at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:147) at com.sun.proxy.$Proxy64.certificateRequest(Unknown Source) at MyClass.myMethod(MyClass.java:1) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81) at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144) at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161) at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160) at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99) at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389) at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347) at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102) at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326) at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) at org.glassfish.jersey.internal.Errors.process(Errors.java:315) at org.glassfish.jersey.internal.Errors.process(Errors.java:297) at org.glassfish.jersey.internal.Errors.process(Errors.java:267) at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1457) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748)

When i try to send this throwable to rollbar when using the following code:

new PayloadSender().send(Payload.fromError( TOKEN,ENVIRONMENT,throwable,custom));

i get a com.rollbar.utilities.ArgumentNullException with the following stack trace
com.rollbar.utilities.ArgumentNullException: 'filename' cannot be null at com.rollbar.utilities.Validate.isNotNullOrWhitespace(Validate.java:20) at com.rollbar.payload.data.body.Frame.<init>(Frame.java:65) at com.rollbar.payload.data.body.Frame.fromStackTraceElement(Frame.java:106) at com.rollbar.payload.data.body.Frame.fromThrowable(Frame.java:88) at com.rollbar.payload.data.body.Trace.fromThrowable(Trace.java:50) at com.rollbar.payload.data.body.Body.trace(Body.java:61) at com.rollbar.payload.data.body.Body.fromError(Body.java:49) at com.rollbar.payload.data.body.Body.fromError(Body.java:34) at com.rollbar.payload.Payload.fromError(Payload.java:52) at MyClass.myMethod(MyClass.java:1) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81) at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144) at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161) at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160) at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99) at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389) at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347) at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102) at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326) at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) at org.glassfish.jersey.internal.Errors.process(Errors.java:315) at org.glassfish.jersey.internal.Errors.process(Errors.java:297) at org.glassfish.jersey.internal.Errors.process(Errors.java:267) at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1457) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748)

It seems to me that this caused because on the "Native method' occurrences this code of your "com.rollbar.payload.data.body.Frame" implementation returns null:

https://pastebin.com/UR0m7MHm

Here's what on Oracle JDK's documentantion (https://docs.oracle.com/javase/7/docs/api/java/lang/StackTraceElement.html) for "java.lang.StackTraceElement" instances' "getFilename()" method:

public String getFileName()
Returns the name of the source file containing the execution point represented by this stack trace element. Generally, this corresponds to the SourceFile attribute of the relevant class file (as per The Java Virtual Machine Specification, Section 4.7.7). In some systems, the name may refer to some source code unit other than a file, such as an entry in source repository.

Returns: the name of the file containing the execution point represented by this stack trace element, or null if this information is unavailable.

Given this, i would say that should reconsider your validations since this means that a lot of "real-world" stacktraces cannot be sent to rollbar.

Payload sending is currently not batched. Every event is sent as a separate http request, with a fresh connection. This seems quite gratuitous, and limits the number of messages we feel comfortable sending.

Could this be changed to batch multiple events into a single request? E.g. a background sender on a thread, firing off a fixed number of requests at a time, with potentially many log messages being enqueued and sent in one go.

FWIW this is how Logentries and other log client jars do it.

It's not terrible, but it's inconvenient that BodyContent is package-private instead of public. I'm guessing this is an oversight.

It means that Body.Builder.bodyContent() has to be called with one of the public subclasses of BodyContent, and prevents something like

BodyContent content = figureOutContent();
new Body.Builder().bodyContent(content);

Currently, sending a throwable report is blocking, and uses the basic built-in HttpURLConnection client from the JDK. This means that reporting a throwable in the natural way during request handling will delay service time unless users go to the trouble of wrapping Rollbar in an abstraction that allows them to hand off invocations to another thread. While that's possible, it would make the life of all users a lot easier if they could rely on the Rollbar client using nonblocking i/o so they could "fire and forget" requests.

This would also be a natural opportunity to use a more full-featured http client like https://github.com/AsyncHttpClient/async-http-client or https://hc.apache.org/httpcomponents-asyncclient-dev/index.html. The built-in client is very limited in its configurability.

If this is of interest, I'm happy to contribute a PR.

It would be nice to be able to report telemetry events for Android apps.

The API docs are pretty clear that it's ok to send non-standard attributes in the item JSON, but rollbar-java 1.0.0 has removed this capability. (It could be done for some, but not all, objects in 0.5.4.)

Would you consider re-adding this capability?
I find it useful to record things like the response code, the timestamps at the beginning and the end of the request, extra person attributes, etc.

I'm sorry I wasn't able to get this feedback to you before 1.0.0 was released!

Not sure how open you are to changing build systems after all the other stuff I've offered to swap out, but Gradle is pretty radically superior to Maven:

• It's faster (most builds speed up when converted to the equivalent Gradle build)
• It's more reliable (if you haven't fallen afoul of Maven's dependency resolution inconsistencies, you will)
• It's parallel-friendly (parallel builds have been a thing for a long time, and its downloaded artifact cache is safe to use concurrently, unlike Maven's)
• It's way more flexible when you need to do custom stuff
• There's nothing to install, ever: the build tool version and bootstrap is embedded in the project, so there's never "it works on my machine" because of different build tool versions. This also makes it really easy to use in CI.
• It's well supported in IntelliJ and Eclipse

And of course, I'll PR this as well if you want.

I get the following Exception when creating a custom Payload from a Throwable:
com.rollbar.utilities.ArgumentNullException: 'filename' cannot be null.

I do not understand why the Frame class calls com.rollbar.utilities.Validate.isNotNullOrWhitespace during construction. The Throwable which is passed could have StackTraceElements assigned whose filename is set to null.

As a workaround I currently rewrite the StackTraceElements of my Throwables to substitute a null filename with a String such as "[unknown]". But I think the framework should do this.

What do you think?

Here is the full StackTrace without workaround applied:

com.rollbar.utilities.ArgumentNullException: 'filename' cannot be null
	at com.rollbar.utilities.Validate.isNotNullOrWhitespace(Validate.java:20)
	at com.rollbar.payload.data.body.Frame.<init>(Frame.java:65)
	at com.rollbar.payload.data.body.Frame.fromStackTraceElement(Frame.java:106)
	at com.rollbar.payload.data.body.Frame.fromThrowable(Frame.java:88)
	at com.rollbar.payload.data.body.Trace.fromThrowable(Trace.java:50)
	at com.rollbar.payload.data.body.Body.trace(Body.java:61)
	at com.rollbar.payload.data.body.Body.fromError(Body.java:49)
	at com.rollbar.payload.data.body.Body.fromError(Body.java:34)

Details in https://app.clubhouse.io/rollbar/story/3531/play-framework

@basoko assigning this to you for now, but if you don't get a chance to look at it in the next couple of days, let's drop into the backlog.

It would be nice to be able to do something like:

compile("com.rollbar:rollbar-spring:x.x.x")

and be able to not have to configure the @ControllerAdvice. Better yet, it would be nice to have the library using Spring Boot Autoconfiguration so that the user of the library would only be responsible for setting properties.

We need to add a module for java web projects integration.

This module should track information from the request and append it to the errors.

http://search.maven.org/#search%7Cga%7C1%7Crollbar

0.4.0 is the latest available for download.

Update all the documentation with the new API information and examples.

I'd like all error logs to be pushed to rollbar automatically.

I intend to move (most of) the functionality from https://github.com/fstech/rollbar-logback to a new module ("rollbar-logback") in this project.
@Crisfole please let me know if it works for you.

I also want to add a spring-boot starter to wire things together in spring-boot application and allow some customization.

The current link is https://github.com/rollbar/rollbar-java/rollbar which brings you to 404.

I'm attempting to use this library in an Openfire XMPP server plugin.

My setup is like this:
public static final Rollbar rollbar = new Rollbar("myaccesstokenblahblah", "development");

Later in the code I use it like so:

rollbar.debug("Bot sent message");

It seems to be sending something to api.rollbar.com (at least according to Wireshark, which is very hard to read), but nothing appears on the items list on the rollbar UI.

Could this be an issue with my code? My rollbar account settings? The java code itself?
I'm stumped.

Right now to work with rollbar-android you need to use

compile('com.rollbar:rollbar-android:1.0.0-beta-2@aar'){transitive=true}

Because of the way the packages are published. It should just work with

compile('com.rollbar:rollbar-android:1.0.0-beta-2')

Fix the packaging and publishing to make that true.

Crashlytics does this already and we have a user requesting this.

We're collecting the simple class name, e.g. throwable.getClass().getSimpleName(). It'd be more useful to collect the full class name, e.g. throwable.getClass().getName().

The API does not support batching. The API should add support for batched requests (I don't know if there's a public ticket system for the rollbar API) - but once that's done the client should add support for it as well (and buffering with a pool + batching should be enabled by default)

See also #30

Rollbar rollbar = new Rollbar("key", "env") leaves rollbar.getLanguage() == null, despite constructor javadoc indicating that language would default to "java". Conversely, rollbar.getFramework().equals("java") instead.

Would be great to list items by date and by any other filter (maybe log level).
Also allow deletion of items by id / list of ids.

New to rollbar and trying to integrate in Android Studio for Android app. Doc is a mess of old and new. Main page references 0.2.0, but 1.0.0 is referenced later. Is there a guide for integration and catching uncaught errors from scratch with 1.0 without all of the upgrade noise?

I've put

• compile('com.rollbar:rollbar-java:1.0.0') in my build.gradle,
• access token in AndroidManifest.xml
• Rollbar.init(this);
• import com.rollbar.android.Rollbar;
  in MainActivity
  but still, I cannot resolve the Rollbar symbol.

Is it just no longer possible to add custom fields to person data in rollbar-android 1.0.0? The new method just accepts id, name, email instead of a JSONObject.

https://github.com/rollbar/rollbar-java/blob/master/rollbar-android/src/main/java/com/rollbar/android/Rollbar.java#L265

Is this functionality not be supported anymore or is this feature just not in 1.0 yet?

We should have a log4j module; it would depend on the other modules (much like rollbar does) to log errors.

The API describes the timestamp field as a unix timestamp. However, rollbar-java's default TimestampProvider provides a "java" timestamp, which is based on milliseconds instead of seconds.

The rollbar UI doesn't seem to interpret this:

I dislike how the api loses milliseconds, but it's probably best to be spec-compliant and divide the java timestamp by 1000 to dump the milliseconds.

Pull in rollbar-android as a submodule. Make it depend on the other modules to make the interface consistent.

[USER]:
I have an Android app that sends reports to Rollbar just fine from an emulator (Android 7) or a MotoE device (Android 6), but not from a Huawei Honor (Android 7). What could possibly be causing that?

The existing by-hand JSON serialization, while workable, doesn't seem like it's adding a lot of value. A fair amount of code and complexity could be removed by using an existing mature JSON library like http://wiki.fasterxml.com/JacksonHome. Hopefully reporting exceptions isn't a frequent occurrence, but Jackson is also very fast.

If this is of interest I'm happy to contribute a PR.

java

I've seen you've added my previous issue (#67) to the changelog for the 1.0.0-beta-1 version. Thank you.
Now i've updated to that version but now NONE of my issues are being sent to rollbar!

I mean... Where's the javadoc for the 1.0.0-beta-1 version?
I'm using this code...

`public static final Rollbar rollbar = new Rollbar(withAccessToken("ACCESS_TOKEN").environment("production").build());

Map<String,Object> custom = new HashMap<>();
custom.put("fingerprint",code);
custom.put("message",message);

rollbar.critical(myThrowable,custom);`

This is supposed to send the payload to rollbar right?
Seriously guys... I need to have this on components that are being used in production ASAP.
And let's pretend that i'm not actually having to resort to a beta build in such environments in the first place.

I found some room for improvement in RollbarSerializer (version 0.5.4). Consider the following Scala code as an example:

val customData = Map(
  "customParam" -> Some("hello world") //String -> scala.Option[String]
)

val customDataJava = customData.mapValues(_.asInstanceOf[AnyRef]).asJava //java.util.Map<String, Object>

rollbar.error(new RuntimeException("Some error"), customDataJava)

The JSON payload will have the following format in this case:

{  
   ...
   "data":{  
      ...      
      "custom":{  
         "customParam": //No value here
      },
      "notifier":{  
         "name":"rollbar",
         "version":"0.5.4"
      }
   }
}

...which will result in a BadRequest status and a could not parse json message.

I think this could be improved by sending a toString() value when all other options are exhausted here.

I'll gladly open a PR for this, if this kind of behaviour would be acceptable for you.

I created a pull request that contains a test to drive out a fix, but I am not sure which direction you'd prefer the fix to go. Should the constructor include another required argument, or should the construction of the object be more defensive?

#4

We need to add a module that contains the android integration.

rollbar-java uses a json array for each request parameter. Semantically this is correct, but it seems the rollbar UI renders the array as a String, which is kinda ugly:

And I didn't check, but I'd guess RQL queries would need to have to use something like WHERE request.get.foo = '["bar"]'.

It'd be nicer if, when there is only one value for the parameter, the rollbar UI and RQL mechanism used a simple String instead of an array. Maybe rollbar could do this server-side, but if not, this can definitely be achieved client-side, here in rollbar-java. Some kind of post-processing step could replace lists (of length 1) with the list's single element, before sending the json off to the rollbar API.

and then be able to edit the payload

Let's get some tests running in Travis for rollbar-android using the simulator.

API error: Invalid format. data.body must have either a 'trace', 'trace_chain', 'message' or 'crash_report' property, (but not more than one).

No idea why this is happening,

All I did was add public static final Rollbar rollbar = new Rollbar("KEY", "production");
to the top of my start file and added rollbar.handleUncaughtErrors(); at the of the main void.

Any ideas?