Allow to pass custom serializer and representation_serializer in configuration

[olsavmic]

Resolves #482

Well I can improve the docs but I would say that such compiler pass is rather a hack than proper solution.
The problem with the compiler pass is that it's a modification of the internals and not the public API so it's a subject to change in future releases without any warning.
I know of SerializableInterface and class_serializers but there are use cases when you need to modify "global" behaviour.
I'd prefer to add the representation serializer (and perhaps even the serializer) as optional configuration options.
I can prepare a PR if such modification is a welcome change.

[olsavmic]

Custom serializer can then be registered as a service as usually

App\Logger\SentryReprSerializer:
    arguments:
        $options: '@sentry.client.options'

[olsavmic]

@Jean85 @ste93cry I did not receive any comment on this issue. Can I ask for a review of this PR or a comment on the related issue so we can proceed or close the issue?

Thanks a lot!

[Jean85]

Code looks fine for what I can see. It would require a changelog entry though.
Also, I'll retarget do develop since it's a new feature.

@ste93cry WDYT? Is this a valuable feature in your opinion?

[ste93cry]

Is this a valuable feature in your opinion?

Yes, it is. In the future though I would like to see both serializers gone and replaced with either a refactored version or a third party lib so that we don't have to maintain the mess they are right now

[ste93cry]

Stricly speaking about the current PR's code I have nothing more to say besides great work, however I'm now wondering if this is the best way to tackle this problem. The fact is that the serializer requires the options of the client whose service is not defined until it gets created by the SentryExtension during the compilation phase of the container. In turn, when I coded the service of the options I made it private because my though was (and is) that to access them you should pass from the client: the options is not something meant to be injected as a normal service because it belongs to a specific client instance. Maybe, instead of allowing to set the serializer instance, we should instead use a factory that given the options returns an instance of the serializer, forcibly making people aware that each client must have its own serializer instance (which usually doesn't happen)?

[github-actions]

This pull request has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀