Logback Appender configured but Raven.getStoredInstance() is null

[matty]

Trying to use Breadcrumbs or Raven.getStoredInstance() throws a NullPointerException. See the error below.

java.lang.NullPointerException: null
	at com.getsentry.raven.event.Breadcrumbs.record(Breadcrumbs.java:23)

As per documentation https://docs.sentry.io/clients/java/modules/logback/ it shouldn't be null and should work, is this correct?

[bretthoerner]

Hey @matty, this is a known (but poorly documented) issue because appenders are lazy initialized only when the first message is logged.

This has been fixed in the overhaul/refactor/rename to sentry-java which I hope to release this week: #381

[matty]

@bretthoerner Thanks. Is this available now on the beta?

[bretthoerner]

Yeah, beta2 should work. But note that I still need to properly document 1.0, the main change is that you no longer configure Sentry in your logging configuration file (because we need to be able to find and statically init the client at any point in time outside of the logging config). To be clear, you still need to add the appender, you just don't set the dsn or anything Sentry related there anymore.

The easiest way is to use the SENTRY_DSN environment variable... there is also a sentry.properties file now but I need to document it. Also... if you do any DSN configuration we dropped all the raven. prefixes... Ya, I need to document this badly. That's the only real blocker for release.

[matty]

@bretthoerner Great, I am new to implementing Sentry so its a good for me to start here before I place Breadcrumbs etc all over the code. Just need to know how to configure it as I tested it and it does throw a bunch of errors.

I previously configured it by setting environment variables using System.setProperty("sentry.dsn", sentryDsn); as an example. Be great if you can get some docs up soon.

[bretthoerner]

The sentry.dsn property will still work. We also removed the Breadcrumbs class, it's simpler now. Check out logWithStaticAPI: https://github.com/getsentry/raven-java/blob/sentry-1.0/docs/usage.rst

[matty]

@bretthoerner All worked out. May have found a slight issue. Setting sentry.servername property is set as a System.setProperty(... and it comes through fine with:

SentryClient sentryClient = SentryClientFactory.sentryClient();
sentryClient.sendMessage("This is a message via sentryClient");

But using SLF4J with

log.error("This is an error via logback for Sentry");

it says "localhost" not the server name specified!

[bretthoerner]

So SentryClient sentryClient = SentryClientFactory.sentryClient() is making an instance for you to pass around and use manually, it's preferred that you use the static API (the same one the appender uses) like Sentry.capture("message").

What must be happening is your static Sentry client is being initialized before you set the system property. It's much preferred to configure your system from "outside" of your application runtime, either by passing the property to your JVM or by creating a sentry.properties file.

java -Dsentry.servername=foo ... will set the property to ensure that it is set for the full lifetime of the JVM (so that when Sentry initializes the server name will be stored properly). Or use environment variables: SENTRY_SERVERNAME=foo ./run-your-app-here

Or: create a sentry.properties file in the root of your src/main/resources and put servername=foo ... but it seems odd to me to hardcode the servername in your codebase.

[matty]

@bretthoerner Is there anyway to set it in code without sentry.properties or -Dsentry.servername=foo properties?

The app is a web application so it gets packaged as a war file and deployed in a Servlet container so properties like that can't be passed.

It has to be configured in code somewhere, whether its via the static API to set these? The variables that need to be set are like environment, release, server name which all change depending on how its run/built etc so it needs to be dynamically set.

It also uses Spring Framework.

EDIT: The logback appender doesn't seem to use Sentry.getStoredClient() as If I set servername in there it doesn't use it.

[bretthoerner]

@matty Oh, gotcha, try this out:

        // this will overwrite the statically stored client (if there is one) and return it to you for configuration
        SentryClient client = Sentry.init();
        client.setServerName("foo");
        client.setRelease("bar");
        client.setEnvironment("env");

        // this will use the statically stored client, just like Sentry.capture
        logger.error("Error message");

[bretthoerner]

Oh, and if you don't need to force re-init, you can just do Sentry.getStoredClient(), which will attempt to lazy initialize the client (once), otherwise return the stored one.

[matty]

@bretthoerner I have logback configured like:

<configuration>
    <include resource="org/springframework/boot/logging/logback/base.xml"/>
    <logger name="org.springframework.web" level="DEBUG"/>

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>

    <appender name="Sentry" class="io.sentry.logback.SentryAppender">
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>ERROR</level>
        </filter>
    </appender>

    <root level="info">
        <appender-ref ref="STDOUT" />
        <appender-ref ref="Sentry" />
    </root>
</configuration>

And then I did this:

// this will overwrite the statically stored client (if there is one) and return it to you for configuration
        SentryClient client = Sentry.init(sentryDsn);
        client.setServerName("foo");
        client.setRelease("bar");
        client.setEnvironment("env");

        // this will use the statically stored client, just like Sentry.capture
        log.error("Error message");

Like you said but passing the DSN on init and still Sentry is not showing the release, environment and server name is "localhost" (the default)

Is it possible the client is being overwritten or is the appender supposed to use it?

[bretthoerner]

Hmm, that's almost exactly my example. I put the configuration lines above the logging here: https://github.com/getsentry/raven-java-examples/blob/sentry-1.0/sentry-java-logback-example/src/main/java/io/sentry/example/Application.java#L11

And when I ran the code those fields were all properly set. I wonder if this was a bug in beta2? I am using the HEAD of the sentry-1.0 branch currently. I can make another release (it'll take a few hours to appear in Maven Central), or if you're testing this locally you could try to make install on that branch to install SNAPSHOT in your local repo.

[bretthoerner]

Hmmm, I just tried swapping out beta2 on my example and it also worked...

[bretthoerner]

To answer your earlier question, the appender just naively calls Sentry.capture: https://github.com/getsentry/raven-java/blob/sentry-1.0/sentry-logback/src/main/java/io/sentry/logback/SentryAppender.java#L105

Which just gets and uses the statically stored client: https://github.com/getsentry/raven-java/blob/sentry-1.0/sentry/src/main/java/io/sentry/Sentry.java#L176