Clojurians Log v2

Huh I thought juxt lib required deps.edn

pack.alpha is for deps.edn projects only so with Leiningen, Lukasz's example would be enough

Is there a good Clojure library for image manipulation? I have a bunch of .png and .jpg files that I need to resize

if no one has good library recs, image magick on the command line is sick

yeah image magick is really good (and you can shell out to it with whatever scripting solution you like :))

I've also used https://github.com/mikera/imagez a few times, don't remember much of it though

Yeah I’d love an alternative to Image Magick mostly just because I want to practice Clojure more (I’m a beginner and wanting early projects)

@rob370 You could practice Clojure using babashka and then shell out to image magick, if this is just for scripting and not a long running JVM production app or something

But else the imagez library should in theory work as well, on the JVM

image magick is a disaster as soon as you actually care about not blowing things up

i've used the twelve monkeys library for doing imageio (compositing, resizing, thumbnails) https://github.com/haraldk/TwelveMonkeys

sure it's not clojure but it's not hard to use

I’m curious if you could elaborate on this, as I’m actively considering shelling out to graphicsmagick or imagemagick for something I’m working on 🙂

it's a vulnerability, you need to learn to write its policy file so you don't accidentally your server to some attacker

not to mention you're shelling out to an external binary which in itself is slow

it will keep throwing errors at you in the most arcane and mysterious ways (depending on how you call it) so good luck figuring out what actually is wrong when it fails

Good points. And thanks for sharing that twelve monkeys library, I hadn’t come across it yet.

i'm actually in the middle of rewriting our image processing from ruby-calling-imagemagick in clojure/java imageio because the former combination is just slow and vulnerable and complicated and fragile

if you do try imageio/twelve monkeys then feel free to throw questions at me if you get stuck haha (though i'm not doing complicated graphics editing, just simple compositing/resizing/cropping)

can you say more about how it's a security disaster? when would it be exposed to users?

when your user uploads an image that you want imagemagick to convert

At work we use both the mikera/imagez library and the TwelveMonkeys libraries. We do a lot of resizing, rotation, and cropping.

On java 11, we're getting the following warning on startup: > WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance. We currently think that this is caused by the use of log4j which is a multi-release jar, including specific code for different jvm versions. It seems that depending on a multi-release jar makes the jar you create a multi-release, but it seems you need to set it yourself. We are still creating an uberjar with lein at the moment. Does anyone know if there's a way for lein to add this configuration? It seems I can manually do it myself with jar umf manifest-update target/uberjar.jar where manifest-update is a file with Multi-Release: true\n.

https://github.com/technomancy/leiningen/blob/master/sample.project.clj#L453

You can set arbitrary keys in the manifest like so

oh thank you. i was looking for something specific to multi-release and didn't think to look for arbitrary manifest entry

i'm still a bit surprised that multi-release is transitive like this. depending on a jar with this requires your own jar to set this

Alternatively you could view it as a bug in lein where uberjars are losing critical information

Jars are not really transitive

It isn't that depending on a jar requires your jar to set it

When you build an uberjar you create a whole new jar

thanks. those are good points. I'll open up an issue on lein about it.

The process is basically take the jars and unzip into the same place and then rezip, to merge the contents

Which is of course problematic when you have conflicts, and thjar manifest is something that will always conflict

yeah. i wonder if depstar handles this correctly

it does

pretty sure @seancorfield did the correct thing

it seems he did. awesome

of course, he's sean!

another thing lein does with uberjars is propagate the module-info.class from modularized jars

this makes the whole uberjar modularized -- which it shouldn't be

kind of the opposite problem

anyways, depstar handles both of these cases correctly

depstar also handles the log4j2 plugin cache correctly which you need if you build an uberjar with multiple dependencies that each include some log4j2 plugins (there is a Leiningen plugin that will “fix” lein uberjar’s behavior).

This is sort of how the original PSP was hacked: https://en.wikibooks.org/wiki/PSP/Homebrew_History#The_TIFF_Exploit By exploiting a buffer overrun bug in libtiff the hackers were able to run unsigned code, essentially by loading an image from a memory card