In case you need to marry SBT + Artifactory with Jenkins Pipelines – and like me, you don’t want to post the Artifactory Credentials in a public accessible place on the Jenkins Agent, here comes your solution!

First, create a secret containing the username + token/password of the user that should be used by jenkins. In my case, this secret is called acme-jenkins-artifactory-access-token

Then, during your pipeline, get the secret in an environment variable and during the build, post it in a credentials.sbt in the current working directory. This way, sbt will pick up your credentials and uses them to authenticate against your Artifactory to resolve artifacts.


Alternatively you could also create a “secret file” which already has the contents I’m here creating during the build and then just copy that to the current working dir. As I don’t want to create yet another secret containing the same credentials, I’ve chosen this approach.

At my current task, I had to make sure a native library is able to be loaded. I didn’t want to adjust the parameters of the JVM for this, so I had to patch the java.library.path at runtime.

This post is inspired by this post


So, this code (in Scala, but its quite similar in Java) consists of two parts:

  1. Getting the current value of the java.library.path system property
  2. Making sure its actually used by the JVM by doing some reflection hacky stuff.

Getting the current value of the java.library.path system property L7-16

This is straightforward. We do a System.getProperty and then just retrieve it, check if the path we want to add is already there or not. If not, we add it and then set the property.

Making sure its actually used by the JVM L18-23

This is the tricky part. We have to use reflection to get access to the sys_path field of the Classloader. This is usually set to the path where the RT.jar file is located. We make the field accessible, get its current value, then set it to null and set it back to its previous value. Changing the fields value actually triggers the reloading of the paths’, so that the java.library.path variable is read again and used from now on.

Compared to the inspiration post by Fahd Shariff, we make sure to set the sys_paths field back to a reasonable value, else the JVM is unable to use other native-functions, e.g. `java.nio` and you would get errors like:

[info] java.lang.ExceptionInInitializerError [info] at java.base/sun.nio.fs.UnixFileSystemProvider.copy(UnixFileSystemProvider.java:258) [info] at java.base/java.nio.file.Files.copy(Files.java:1295) [info] at com.acme.calculation.demo.GamsIntegrationSpec.$anonfun$new$52(GamsIntegrationSpec.scala:278) [info] at zio.internal.FiberContext.evaluateNow(FiberContext.scala:361) [info] at zio.internal.FiberContext.$anonfun$evaluateLater$1(FiberContext.scala:775) [info] at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [info] at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [info] at java.base/java.lang.Thread.run(Thread.java:834)
Code language: PHP (php)

Recently I had to push in a Jenkins Pipeline to a git repository that was only accessible through https with username + password.

Attempts to provide the password in the url like https://user:p@s$w0rd@host.com/ failed, as apparently the password contained already a @ character and thus messed up the url.

A good colleague pointed me to .netrc which apparently is used, as git itself is using curl under the covers. The only problem was, that – from what is publicly documented – the .netrc file has to be in the $HOME folder, which would mean, that all other jobs on the Jenkins instance could also use our credentials.. while in theory possible, its a NOGO in our situation.

In the end, I’ve ended up with this solution.


  1. retrieving the credentials to be used and store them in an environment variable
  2. create a local .netrc file in the project directory
  3. then, when using git, override the $HOME variable and set it to the current directory (pwd), thus making git treat the current directory as the users home and look here for the .netrc file instead of the real home, which could be accessed by other users.

At my current project, we use snapshots for versioning certain important states in our application. As we have the requirement to “jump back” to these states for some specialised queries, we needed a way to access a specific snapshot, without having to create a Persistent-Actor / Eventsourced-Behaviour that could mess up the journal of that Entity or would start to consume the event-log after loading the snapshot.

So, basically what we needed is the future-api that is already defined in SnapshotStore.scala in Akka.

Unfortunatelly, this API is not easily accessible, as it can only be implemented inside an Actor and we’re not supposed to access an actors internal state from the outside, thus making it impossible to use the already provided Future-based API.

As a workaround, I’ve created these “helpers” to easily access the snapshot-store and interact with its API.


Here, I first extracted (bascially copy-pasted) the future based API from SnapshotStore.scala, so I can easily reference the type later – I called this trait SnapshotStoreBase.

Then I created the “SnapshotStoreAccessor”, which basically given the ActorRef of a SnapshotStore gives you access to its Future-based API.


So by now, we have a trait that models the future-based way of accessing the Snapshot-Store and an implementation that allows us to access this using the Ask-Pattern.

What is still missing is a way to get a hold on the ActorRef of the SnapshotStore, so we can use that one together with the SnapshotStoreAccessor.

For this, I created the SnapshotStoreGetter:


Here, we first have a Method “getSnapshotStoreActorRef” which uses an internal Akka API to get the reference to the SnapshotStore actor of the given “snapshotStorePluginId”. As the underlying method in akka.persistence.Persistence is scoped to the akka package, we have to make sure this accessor is also in the akka package.
The “getSnapshotStoreFor” method than just takes that ActorRef and created the SnapshotStoreAccessor. Finally, the “getSnapshotStore” is our public API, giving access to the future-based API by just providing the ID and an implicit ActorSystem.

So how do we now use this to access our Snapshot? Easy! Just look at this example:


When you’re using PostgreSQL together with Slick, chances are high, that you’re also using the Slick-PG library. You probably came to this post, because you try to map your custom ADT to a List/Sequence of that and want to store it as a text[] (or other array) in PostgreSQL. When trying to do so, the compiler gave you an error like:

could not find implicit value for parameter tt: slick.ast.TypedType[List[xxx.UseCase]]

You already tried creating a MappedColumnType[UseCase, String], but for some reason, Slick hasn’t picked it up / is not using it for Sequences / Lists.

Go no further, the solution is near!


Simply create a new JdbcType[List[YourType]] based on the SimpleArrayJdbcType[String] and then use the mapTo[YourType] method.

I hope you found this helpful!

Scala HMac SHA256

21 Nov
2020

As I repeatedly (e.g. every 2nd year) have to find the right code to generate a HMAC SHA256 hash from a string, I’m sharing this (for me and others) here. The tricky part is the String-Format to 64 chars. Most code I’ve found had this set to 32 chars (like used for MD5) which resulted in too short hashes for certain inputs.


I hope you find this useful!

This is mainly a note to self on how to build inheritance hierarchies (e.g. Animal -> [Cat / Dog] ) with Play-JSON.



Documentation can be found here:

As mentioned in my previous articles about using VAVR together with Spring, use the following classes to make VAVRs Option and all Collection types based on Seq work correctly with SpringDoc. Just place them in a package that gets scanned by Spring!



A big shoutout to bnasslahsen who provided me with the VavrOptionSupportConverter that I adjusted to work with the collection types (see this issue)

During the Corona crisis, I was in urgent need of a Webcam. While I thought I ordered a Logitech C930e Business webcam, I got shipped a C930c which is basically the same one but the chinese version.

As it is now the second time I was spending time to find drivers / controller software for this piece of hardware, I’ll save the driver links here (for myself and whoever finds this):

MacOSX: LogiCameraSettings_3.0.12.pkg taken from here: https://support.logi.com/hc/en-001/articles/360024693154-Downloads-Webcam-C930e – yes I know it says c930e), but the software works:

For Windows 10, this package worked for me:

https://download01.logi.com/web/ftp/pub/techsupport/cameras/Webcams/LogiCameraSettings_2.10.4.exe

I’m not really sure why Logitech has different versions for europe and china, or why they don’t let us flash the european firmware on the china one, but they’ll probably have their reasons. As my right the return the camera is already over, I’ll be sticking with it for now and just handle the few chinese characters.

As already documented in my previous article about Spring and VAVR, I’m using the Future’s provided by VAVR as return types in my controller.

What I’m also using, is the SpringDoc OpenAPI library to generate my OpenAPI specification. By default, SpringDoc has no clue about VAVR and how to handle its Future type.

Thus, by default, SpringDoc transfers the VAVR-Future into a wrapper and thus creates a Swagger/OpenAPI-Component for this wrapper, having all the methods of VAVRs Future instead of the type it is wrapping.

To disable this, I added the following call to the class configuring my SpringDoc integration:


I’ve specified it in a static block in the component so that it calls the also static method “addResponseWrapperToIgnore” in SpringDocs’ ConverterUtils, telling it to treat VAVRs Future as a wrapper (or better to ignore it and look at the underlying value).

top