dpsoft on 1.1.5
dpsoft on v1.1.5
dpsoft on 1.1.5
* Update Hdr * lazy vals in Kam… (compare)
ivantopo on master
clean references to scheduled r… (compare)
All Kamon modules that need configuration ship with a reference.conf file where default settings are contained and you are free to override any of those values by supplying your owns in your application.conf file.. So it seemed to me like I could just override individual values in application.conf. I didn't realize that the Maven assembly plugin would do otherwise.
--conf "spark.executor.extraJavaOptions=-javaagent:kanela-agent-1.0.1.jar"to the spark-submit command, but the Kanela banner does not print, nor does my failed statement processor get called when there is a SQL error.
You'll have to excuse if my questions have been asked before but I'm not a big fan of gitter as media for Q&A due to the lack of structure and searchability.
Anyways I'm looking at moving to from kamon 1.x -> 2.x but face a few issues.
Have a few customisations I'm trying to lift.
First off kamon.context.Codecs has disappeared from kamon-core.
So how does one now create a custom codec?
The documentation still points to the trait
ForEntry but it seems to have disappeared.
I also have a custom implementation
kamon.akka.http.AkkaHttp.OperationNameGenerator but the trait seems to be gone as well.
No hint in the migration guide either
@ivantopo thx, will peek at the example. The reason for creating a custom codec is to generate a special header in case it is missing. This is part of a utility library shared among many applications so the reason for the codec was to hide it for the apps.
this gave me a single place to mutate the context else one must mutate and set the new mutated context as current
So yeah in practice my need is probably very close the span propagation.
I'll take a look at the default name produced by the built in name generator but there was (at the time) a reason why we implemented our own so I guess we'll still need the possibility to customise the name
I'll peek at that too, though I fear config might be complicated as it's about slicing the URL according to a json api spec
/api/<resource>/<id> -> <resource>
/api/<resource>/<id>/<relationship> -> <resource>-<relationship>
/api/<servicefunction> -> <servicefunction>
The code in Scala is very simple so I would love to just migrate it as opposed to try to config it using complicated rules, it it even would be possible