Multi DSN per Java Application support

[BrowenChen]

Problem Statement

I have a use case where I'd like to separate Projects by team with multiple DSNs in a single JVM application. I tried local testing of a workaround solution (https://github.com/getsentry/sentry-java/compare/feat/multi-dsn-playground) with custom ITransportFactory and EventProcessor which seemed to work. The only issue was that RequestDetailsResolver was package-private in the SDK, so my application didn't have access and I had to rewrite my own RequestDetailsResolver, DSN classes. + SentryClient.SENTRY_PROTOCOL_VERSION within the RequestDetailsResolver was also unaccessible, so I have to hardcode the protocol version.

Solution Brainstorm

Is it possible to make this class public? https://github.com/getsentry/sentry-java/blob/main/sentry/src/main/java/io/sentry/RequestDetailsResolver.java#L10

[adinauer]

Hello @BrowenChen as a workaround can you please put your RequestDetailsResolver in the io.sentry package. We'll discuss internally how we want to support this use case. When you relocate the RequestDetailsResolver as shown on Line 1 of MyRequestDetailsResolver (https://github.com/getsentry/sentry-java/compare/getsentry:f1e4d4c...getsentry:1e6ab41#) you shouldn't have to copy DSN and protocol version.

Ideas for better public API:

• Avoid having multiple copies of SentryOptions

[BrowenChen]

Hi @adinauer, thanks for the info - I don't think we're able to put custom files in our io.sentry jar package since it's a read-only Maven dependency, unless we extract and rebuild the jar manually. Is there an alternative to adding new files to io.sentry on our end?

[adinauer]

@BrowenChen is something stopping you from putting a class into the io.sentry package in your own application?

Also could you please elaborate on why you need to send to different Sentry projects? Is there a feature we're lacking in our product to allow you to use a single project instead?

[BrowenChen]

Hi @adinauer, from our end, I believe we'd have to fork it, make the modification, build the JAR and put it in our artifactory instance to pull in the dependency, and ideally we'd like to avoid maintaining third-party forks.

However, I think we can get tag filtering to work for our use cases, so we can likely stick to a single project across all teams

[adinauer]

@BrowenChen in case you need more help, please let us know. You should be able to simply put a class in the io.sentry package in your own application, then package that up as JAR, WAR or whatever you need as usual and it should just work. No forking or manipulating JARs required.

[stefanosiano]

@adinauer Is there any update on this?

[adinauer]

No update. This is in the backlog. Can't say when we'll get to it yet.

[stefanosiano]

Ah ok, no pressure. Asking just because it came up in the Android sync, since this issue was in the mobile project, but without the Android label. Now I removed it from the mobile project 👍

[adinauer]

In theory this isn't limited to Backend use cases. But that's OK.