Enable the initialization using argument passing style in addition to the callback style configuration.

[metlos]

📢 Type of change

• Bugfix
• New feature
• Enhancement
• Refactoring

📜 Description

Currently, Sentry only allows for callback-style initialization using OptionsConfiguration interface passed into the Sentry.init() methods. This PR makes available to users also the initialization method that merely accepts the SentryOptions instance.

Additionally, I've removed the unnecessary generic parameter on the init method that was made public, because it naturally accepts any subclass of SentryOptions just by inheritance rules.

💡 Motivation and Context

The callback-based initialization is limiting in the injection-based environments like Spring or CDI where instances are produced and injected rather than modified through a callback.

💚 How did you test it?

N/A

📝 Checklist

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

[bruno-garcia]

@metlos if we do this there's no way anymore to run code on the object before we give the user a chance to change things. So to know in what is framework config vs user config becomes more complicated.
Is there a way to just give these frameworks the object we created instead of letting them give us the instance?

[metlos]

if we do this there's no way anymore to run code on the object before we give the user a chance to change things. So to know in what is framework config vs user config becomes more complicated.
Is there a way to just give these frameworks the object we created instead of letting them give us the instance?

So basically you need to distinguish between Sentry framework config vs user config? So what about just using 2 different objects for that?

[bruno-garcia]

@metlos everything gets set to an instance of SentryOptions but if a user programatically sets a value, that must take presedence (override) anything set by some framework integration.

So if the frameworks read a JSON config and binding the values to SentryOptions we need that to happen before applying the user defined callback (programaticaly defined settings).

[metlos]

Ok, let's keep this PR open and I'll try to come up with a reasonably "natural" of doing things in Spring that would not require this change. If I am not able to come with something similar to what we have in sentry-java, we can discuss it further here..

[bruno-garcia]

Leave a review until we make a decision on this.
As per @metlos last comment

[marandaneto]

closed in favor of https://github.com/getsentry/sentry-android/blob/feat/sentry-java/sentry-core/src/main/java/io/sentry/core/Sentry.java#L127-L135