Skip to content
This repository was archived by the owner on Aug 30, 2023. It is now read-only.

Conversation

@maciejwalkowiak
Copy link
Contributor

📢 Type of change

  • Bugfix
  • New feature
  • Enhancement
  • Refactoring

📜 Description

Added console application sample. Code is a direct translation from console sample in sentry-dotnet repository excluding features that are not implemented in sentry-java.

Gradle contains minimal set of configuration to avoid confusion what's required to use Sentry. The only extra task that is added is one that builds fat jar - it's a subject to discussion if we need it here.

💡 Motivation and Context

Sample console application is a living documentation and guides users through Java SDK features.

💚 How did you test it?

📝 Checklist

  • I reviewed submitted code
  • I added tests to verify changes
  • All tests passing
  • No breaking changes

🔮 Next steps

Sample code is a direct translation from console sample in `sentry-dotnet` repository excluding features that are not implemented in `sentry-java`.
Copy link
Member

@bruno-garcia bruno-garcia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really promising! Thanks @maciejwalkowiak
Let's wait on @marandaneto's feedback, meanwhile I left some comments.

I'd also suggest we merge this into master. What do you think?
It's just a sample project and helps show off our API. Besides pushScope everything behaves the same in Android.

// The SDK is able to detect duplicate events:
// This is useful, for example, when multiple loggers log the same exception. Or exception is
// re-thrown and recaptured.
Sentry.captureException(exception);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure we have this de-duplication here though, need to check

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, the deduplication does not happen.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, it's a TODO


// Console output will show queue being flushed. Task completes then and timeout is never
// reached (you don't need to wait a day :)
Sentry.flush(10000);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure this will work. It should but we need to work on flush

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right - it doesn't. SentryClient#flush is literally // TODO: Flush transport :-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, I'd rather keep flush out of this sample, but change it to close which is already implemented?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since close is executed anyway at the JVM termination I am not sure if this wouldn't be confusing. I'll leave it up to you and @bruno-garcia. This is anyway not the final version of the sample as it will get likely updated once more features are added to Java SDK.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's true, if the integration call closes automatically by default, no need, or, to still sample it, but add as a comment that a default integration will do it, but they still could do it manually. @bruno-garcia ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in #502.

Comment on lines +15 to +28
val fatJar = task("fatJar", type = Jar::class) {
archiveFileName.set("${project.name}-fat.jar")
manifest {
attributes["Main-Class"] = "io.sentry.samples.console.Main"
}
from(configurations.runtimeClasspath.get().map { if (it.isDirectory) it else zipTree(it) })
with(tasks.jar.get() as CopySpec)
}

tasks {
"build" {
dependsOn(fatJar)
}
}
Copy link
Contributor

@marandaneto marandaneto Jul 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nothing against doing it, but what's about sparing some bits and using a Gradle plugin? this might break when upgrading Gradle versions and usually plugins react fast to it.
eg https://github.com/johnrengelman/shadow
Also, is it really common that people copy paste fatjars instead of using maven dependencies?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to avoid extra dependency that's why I don't go with plugin.

If people build standalone CLI apps then it's common to build fat jars. It only depends if we want this example to show the code or also to actually let users run the sample application.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe both, but if they run, it'll be thru the IDE anyway, we don't export/allow to download the final jars/apks, it might be a good idea, but for that, we also have our official examples repo.
https://github.com/getsentry/examples

the idea of having samples on this repo is to easier the development, so you can run and debug the SDK and samples easily.

of course also a resource of learning.

that said, I'd go either with the plugin, so we don't need to maintain this piece of code or to not generate a fat jar at all.
thoughts @bruno-garcia ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am getting convinced that we can just remove fat jar building. It can be always added later if we find there is a need for that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess removing then is best, otherwise tbh I'd also avoid the dependency and just leave those lines of code.
If gradle changed and broken I'm sure the plugin would take more time to catch up than us just patching the fix here.

I guess it boils down to how much pain have you had because of dependencies in your life. I avoid them as much as possible

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bruno-garcia gradle plugins are not dependencies

options.setDiagnosticLevel(SentryLevel.ERROR); // A good option to have SDK debug log in prod is to use only level ERROR here.

// Using a proxy:
options.setProxy(null); // new Proxy(Type.HTTP, new InetSocketAddress(8090)));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've never tested this class, to be honest, it's pretty much a copy-paste from sentry-java, it's fine to keep here but recently @thinkocapo could not use it for some reason and I still need to figure out if it's a bug or a proxy setup.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed in #502 as I believe we should have only working and tested code in sample. We can add it once we gain more confidence.

Copy link
Contributor

@marandaneto marandaneto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left a few comments/questions but pretty happy with it.
thanks @maciejwalkowiak

@marandaneto
Copy link
Contributor

I'd also suggest we merge this into master. What do you think?

it'd be fine to go into master as this has no breaking changes, just a sample, although #500 should be merged into master too and I'm fine with it, let's do it


public static void main(String[] args) {
Sentry.init(
options -> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd also set:

options.setRelease("[email protected]+1");
options.setSentryClientName("sentry-java/3.0.0");

while we don't read this automatically from the build conf/CI etc...so if people see this example that will land in master, they at least know that this is needed right now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I rather ppl didn't know this existed. We'll start receiving all sorts of interesting values on the server if ppl are pushed to add something here.

@maciejwalkowiak
Copy link
Contributor Author

Once @marandaneto or @bruno-garcia merge #501 I'll add all the polishing to this PR.

@maciejwalkowiak
Copy link
Contributor Author

Closing in favour of #502.

@maciejwalkowiak maciejwalkowiak deleted the samples-console branch July 30, 2020 09:32
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants