search

terl / resource-loader

Getting files out of a JAR or loading a shared library is difficult. We made it easy.
MIT License
19 stars 10 forks source link

Docker issues. #2

Closed chrisjenx closed 3 years ago

chrisjenx commented 4 years ago

Not sure why, struggling to dig into it, but resource loader seems to struggle to unpack resources when running within a docker instance.

I'm trying to get the full stack, but it looks like it never unpacks from the jar correctly:

co.libly.resourceloader.ResourceLoaderException at SealedBoxEncryptorKtTest.kt:15
        Caused by: java.io.FileNotFoundException at SealedBoxEncryptorKtTest.kt:15
chrisjenx commented 4 years ago

Works find on windows/osx

gurpreet- commented 4 years ago

Hi @chrisjenx,

Thank you for raising this. So it's struggling to unpack in a docker image 🤔

  1. What is the base docker image you're running? Just so I can replicate this.
  2. What files were unpacked?
chrisjenx commented 4 years ago

Just to clarify, I don't think this is libly's fault, but does worry me, that it could affect some docker containers. For us we're using a circleci/android container, I'm struggling to get a full stack trace and see what the tmp structure looks like. It's more of an FYI for other people.

gurpreet- commented 4 years ago

Hi @chrisjenx,

Just realised you're the author of Calligraphy! I've used it so many times in my Android projects so thank you very much for that! 😁

I made myself a very brief docker container and tested it. It does indeed crash inside docker containers. This is not ideal at all and I will try and fix it. Example stacktrace:

Exception in thread "main" co.libly.hydride.utils.LibraryLoadingException: Failed to load the library using /tmp/hydride/libhydrogen.so
        at co.libly.hydride.utils.LibraryLoader.loadLibrary(LibraryLoader.java:182)
        at co.libly.hydride.utils.LibraryLoader.loadBundledLibrary(LibraryLoader.java:152)
        at co.libly.hydride.utils.LibraryLoader.loadLibrary(LibraryLoader.java:116)
        at co.libly.hydride.Hydrogen.<init>(Hydrogen.java:30)
gurpreet- commented 4 years ago

Just found a solution. It seems that if you are using alpine images they don't include glibc. The solution provided here is very helpful.

So to solve this issue you can do one of 3 things it seems:

  1. Use a docker base that does in include it. That is, use FROM openjdk:8-jre-slim.
  2. If you don't want to switch your base image then you can Install glibc via RUN apk update && apk add --no-cache libc6-compat
  3. Or alternatively RUN apk update && apk add --no-cache gcompat

Hope that works 👍

chrisjenx commented 4 years ago

Awesome, thanks for looking into this. That's great to hear! We moved to Android tests for this specifically but if we do something on the backend for this I'll give this a go!

Hopefully if anyone else has a similar issue they will see this.

On Sun, Nov 17, 2019, 4:11 PM Gurpreet Paul notifications@github.com wrote:

Just found a solution. It seems that if you are using alpine images they don't include glibc. The solution provided here https://stackoverflow.com/questions/50288034/unsatisfiedlinkerror-tmp-snappy-1-1-4-libsnappyjava-so-error-loading-shared-li/ is very helpful.

So to solve this issue you can do one of 3 things it seems:

  1. Use a docker base that does in include it. That is, use FROM openjdk:8-jre-slim.
  2. If you don't want to switch your base image then you can Install glibc via RUN apk update && apk add --no-cache libc6-compat
  3. Or alternatively RUN apk update && apk add --no-cache gcompat

Hope that works 👍

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libly/resource-loader/issues/2?email_source=notifications&email_token=AAI5DMMJ6IZJB6YUIWCKDS3QUHFTVA5CNFSM4JJ23FLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEIY5UY#issuecomment-554798803, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI5DMOEUGFTVGWZZQSWYQ3QUHFTVANCNFSM4JJ23FLA .