I managed to make my app function.

The problem comes from the way a Spring Boot application packages the jar - 
internally, the jar is different from plain old Java, so the deployment of 
artefacts is also different. The Jnati library that allows the wrapping of the 
InChi factory is not adapted to that special deployment and is simply lost and 
doesn’t find the artifacts in correct places *if it never ran on the system 
before* (case of a brand new minimal image).
The trick I found to make a Spring Boot application using InChis run in Docker 
is not very elegant, but functional. In the container, during the compilation, 
or at the execution of the container, before running the main Spring Boot jar, 
run the simples possible mini POJO jar containing the InChiGeneratorFactory, 
that will create the correct environment.
Now everything works!

This is my Dockerfile:

FROM openjdk:8u171-slim
EXPOSE 8080
VOLUME /tmp
ARG JAR_FILE
COPY ${JAR_FILE} app.jar
COPY inchiPet.jar /

RUN java -jar inchiPet.jar

ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
Where « inchiPet.jar » is the tiny regular jar with only a call to an 
inchiGeneratorFactory, and « app.jar » is my main app.

However, I used a bunch of libraries from CDK and until now, only the InChi 
generator caused this problem within the Spring Boot - Docker ecosystem.

Hope this solution could help anybody encountering this kind of problem in the 
future!



Maria Sorokina, PhD
Steinbeck Research Group
Analytical Chemistry - Cheminformatics and Chemometrics
Friedrich-Schiller-University Jena, Germany
http://cheminf.uni-jena.de

> Le 11 sept. 2018 à 20:57, John Mayfield <john.wilkinson...@gmail.com> a écrit 
> :
> 
> Do you have a different machine to test on? Could also be a factor, alpine 
> gave me a segfault (see attached) but slim works OK.
> 
> [john@toaster jni-inchi-docker]$ more Dockerfile
> FROM openjdk:8u171-slim
> COPY smi2inchi.jar .
> 
> John 
> 
> On Tue, 11 Sep 2018 at 16:23, John Mayfield <john.wilkinson...@gmail.com 
> <mailto:john.wilkinson...@gmail.com>> wrote:
> I'll have a poke around in an alpine container this evening, does seem odd.
> 
> A third option is nested-vm version, we used this in JChemPaint when it was 
> an Applet - (see inchi-nestedvm in https://github.com/JChemPaint/jchempaint 
> <https://github.com/JChemPaint/jchempaint>).
> 
> On Tue, 11 Sep 2018 at 16:03, Maria Sorokina <maria.ssorok...@gmail.com 
> <mailto:maria.ssorok...@gmail.com>> wrote:
> I am building my jar with Maven, but I don’t think that it is the problem, as 
> I tried tu run the jar on a Centos7 VM having just Java and it worked without 
> any problem.
> I also desperately tried the dirty solution of downloading the manifest and 
> the jniinchi-1.03_1-LINUX-AMD64.so <http://jniinchi-1.03_1-linux-amd64.so/> 
> files the ini-inchi seems to search for and put them where it seems to search 
> them within the container, but, of course it failed.
> 
> I’ll try to search for a solution, but for now I’ll just do my thing without 
> containerizing this part of my app. If I find a solution, I’ll post it here. 
> Meanwhile, I’m still very open to any suggestion!
> 
> Kind regards,
> 
> Maria Sorokina, PhD
> Steinbeck Research Group
> Analytical Chemistry - Cheminformatics and Chemometrics
> Friedrich-Schiller-University Jena, Germany
> http://cheminf.uni-jena.de <http://cheminf.uni-jena.de/>
> 
>> Le 11 sept. 2018 à 14:51, John Mayfield <john.wilkinson...@gmail.com 
>> <mailto:john.wilkinson...@gmail.com>> a écrit :
>> 
>> Right, alpine was probably a red herring. Looking again I presume you build 
>> app.jar yourself? It looks like you've removed the MANIFEST.xml that is 
>> needed by JNI InChI to locate the native dependency. How are you building 
>> the JAR?
>> 
>> Unfortunately v1.03 of InChI is all we have for JNI ATM. My former colleague 
>> has been looking at JNA InChI version (https://github.com/dan2097/jna-inchi 
>> <https://github.com/dan2097/jna-inchi>) but this is very different to the 
>> JNI bindings and not a drop in replacement.
>> 
>> John
>> 
>> On Tue, 11 Sep 2018 at 09:48, Maria Sorokina <maria.ssorok...@gmail.com 
>> <mailto:maria.ssorok...@gmail.com>> wrote:
>> I tried the ubuntu 16.04 based image with Java 8 added, I get exactly the 
>> same error, only at the InChi generation. I have the feeling that something 
>> is missing in this minimal linux images for the InChi generator to run 
>> correctly, but I cannot find what.
>> 
>> I also noticed that for an old version of ini-inchi (1.03, and the latest 
>> and only available is 1.6):
>>      npls-db-filler_1  | 2181 [main] INFO  
>> net.sf.jnati.deploy.repository.RemoteRepository  - Searching remote 
>> repository for: jniinchi-1.03_1-LINUX-AMD64 
>> (http://jnati.sourceforge.net/jnati-repo 
>> <http://jnati.sourceforge.net/jnati-repo>)
>> 
>> What am I missing in my configuration ? Knowing that everything works fine 
>> outside of Docker?
>> 
>> The Dockerfile using Ubuntu:
>> 
>> FROM ubuntu:16.04
>> LABEL maintainer="maria.ssorok...@gmail.com 
>> <mailto:maria.ssorok...@gmail.com>"
>> 
>> 
>> RUN apt-get update && \
>>     apt-get upgrade -y && \
>>     apt-get install -y  software-properties-common && \
>>     add-apt-repository ppa:webupd8team/java -y && \
>>     apt-get update && \
>>     echo oracle-java7-installer shared/accepted-oracle-license-v1-1 select 
>> true | /usr/bin/debconf-set-selections && \
>>     apt-get install -y oracle-java8-installer && \
>>     apt-get clean
>> 
>> EXPOSE 8080
>> VOLUME /tmp
>> ARG JAR_FILE
>> COPY ${JAR_FILE} app.jar
>> ENTRYPOINT 
>> ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
>> 
>> Thank you for your help!
>> 
>> Kind regards,
>> 
>> 
>> Maria Sorokina, PhD
>> Steinbeck Research Group
>> Analytical Chemistry - Cheminformatics and Chemometrics
>> Friedrich-Schiller-University Jena, Germany
>> http://cheminf.uni-jena.de <http://cheminf.uni-jena.de/>
>> 
>>> Le 11 sept. 2018 à 00:13, John Mayfield <john.wilkinson...@gmail.com 
>>> <mailto:john.wilkinson...@gmail.com>> a écrit :
>>> 
>>> Unlikely to work in alpine, have you tried ubuntu/debian slim?
>>> 
>>> John
>>> 
>>> On Mon, 10 Sep 2018 at 18:16, Maria Sorokina <maria.ssorok...@gmail.com 
>>> <mailto:maria.ssorok...@gmail.com>> wrote:
>>> Hi,
>>> 
>>> I developed an app using CDK, and in particular it’s InChi Generator. It 
>>> runs perfectly with IntelliJ, and as a jar on MacOS and on CentOS. I wanted 
>>> to make it run within a Docker container (openjdk:8-jdk-alpine with 
>>> additional installation of gcc), the image is created without any problem, 
>>> but when I run the container, I get the following error just once:
>>> 
>>> 
>>> npls-db-filler_1  | 0    [main] INFO  
>>> net.sf.jnati.deploy.artefact.ConfigManager  - Loading global configuration
>>> npls-db-filler_1  | 4    [main] DEBUG 
>>> net.sf.jnati.deploy.artefact.ConfigManager  - Loading defaults: 
>>> jar:file:/app.jar!/BOOT-INF/lib/jnati-deploy-0.3.jar!/META-INF/jnati/jnati.default-properties
>>> npls-db-filler_1  | 5    [main] INFO  
>>> net.sf.jnati.deploy.artefact.ConfigManager  - Loading artefact 
>>> configuration: jniinchi-1.03_1
>>> npls-db-filler_1  | 6    [main] DEBUG 
>>> net.sf.jnati.deploy.artefact.ConfigManager  - Loading instance defaults: 
>>> jar:file:/app.jar!/BOOT-INF/lib/jnati-deploy-0.3.jar!/META-INF/jnati/jnati.instance.default-properties
>>> npls-db-filler_1  | 9    [main] INFO  
>>> net.sf.jnati.deploy.repository.ClasspathRepository  - Searching classpath 
>>> for: jniinchi-1.03_1-LINUX-AMD64
>>> npls-db-filler_1  | 14   [main] INFO  
>>> net.sf.jnati.deploy.repository.LocalRepository  - Searching local 
>>> repository for: jniinchi-1.03_1-LINUX-AMD64
>>> npls-db-filler_1  | 16   [main] DEBUG 
>>> net.sf.jnati.deploy.repository.LocalRepository  - Artefact path: 
>>> /root/.jnati/repo/jniinchi/1.03_1/LINUX-AMD64
>>> npls-db-filler_1  | 16   [main] INFO  
>>> net.sf.jnati.deploy.repository.LocalRepository  - Creating artefact: 
>>> /root/.jnati/repo/jniinchi/1.03_1/LINUX-AMD64
>>> npls-db-filler_1  | 18   [main] DEBUG net.sf.jnati.deploy.source.JarSource  
>>> - Opening jar: /app.jar
>>> npls-db-filler_1  | 19   [main] WARN  
>>> net.sf.jnati.deploy.NativeArtefactLocator  - Error resolving artefact to 
>>> local repository
>>> npls-db-filler_1  | java.io.FileNotFoundException: File not found: 
>>> MANIFEST.xml
>>> npls-db-filler_1  |         at 
>>> net.sf.jnati.deploy.source.JarSource.openFile(JarSource.java:67)
>>> npls-db-filler_1  |         at 
>>> net.sf.jnati.deploy.source.ArtefactSource.loadManifest(ArtefactSource.java:41)
>>> 
>>> And this  every time the InChiGenerator is called in my code:
>>> 
>>> 
>>>  Error loading JNI InChI native code.
>>> npls-db-filler_1  | You may need to compile the native code for your 
>>> platform.
>>> npls-db-filler_1  | See http://jni-inchi.sourceforge.net 
>>> <http://jni-inchi.sourceforge.net/> for instructions.
>>> npls-db-filler_1  | 
>>> npls-db-filler_1  | 1033 [main] INFO  
>>> net.sf.jnati.deploy.artefact.ConfigManager  - Loading artefact 
>>> configuration: jniinchi-1.03_1
>>> npls-db-filler_1  | 1037 [main] DEBUG 
>>> net.sf.jnati.deploy.artefact.ConfigManager  - Loading instance defaults: 
>>> jar:file:/app.jar!/BOOT-INF/lib/jnati-deploy-0.3.jar!/META-INF/jnati/jnati.instance.default-properties
>>> npls-db-filler_1  | 1039 [main] INFO  
>>> net.sf.jnati.deploy.repository.ClasspathRepository  - Searching classpath 
>>> for: jniinchi-1.03_1-LINUX-AMD64
>>> npls-db-filler_1  | 1039 [main] INFO  
>>> net.sf.jnati.deploy.repository.LocalRepository  - Searching local 
>>> repository for: jniinchi-1.03_1-LINUX-AMD64
>>> npls-db-filler_1  | 1039 [main] DEBUG 
>>> net.sf.jnati.deploy.repository.LocalRepository  - Artefact path: 
>>> /root/.jnati/repo/jniinchi/1.03_1/LINUX-AMD64
>>> npls-db-filler_1  | 1040 [main] INFO  
>>> net.sf.jnati.deploy.repository.LocalRepository  - Creating artefact: 
>>> /root/.jnati/repo/jniinchi/1.03_1/LINUX-AMD64
>>> npls-db-filler_1  | 1040 [main] DEBUG net.sf.jnati.deploy.source.JarSource  
>>> - Opening jar: /app.jar
>>> npls-db-filler_1  | 1041 [main] WARN  
>>> net.sf.jnati.deploy.NativeArtefactLocator  - Error resolving artefact to 
>>> local repository
>>> npls-db-filler_1  | java.io.FileNotFoundException: File not found: 
>>> MANIFEST.xml
>>> npls-db-filler_1  |         at 
>>> net.sf.jnati.deploy.source.JarSource.openFile(JarSource.java:67)
>>> 
>>> 
>>> Have anybody tried and succeed using InChiGenerator within a Docker 
>>> container? Which package/library/software I should add to either my Docker 
>>> image, either to my Maven repo to make it work within this container?
>>> 
>>> Thank you for your help!
>>> 
>>> Kind regards,
>>> 
>>> Maria Sorokina, PhD
>>> Steinbeck Research Group
>>> Analytical Chemistry - Cheminformatics and Chemometrics
>>> Friedrich-Schiller-University Jena, Germany
>>> http://cheminf.uni-jena.de <http://cheminf.uni-jena.de/>
>>> _______________________________________________
>>> Cdk-user mailing list
>>> Cdk-user@lists.sourceforge.net <mailto:Cdk-user@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/cdk-user 
>>> <https://lists.sourceforge.net/lists/listinfo/cdk-user>
>> 
> 
> <8u171-alpine.log><8u171-slim.log>

_______________________________________________
Cdk-user mailing list
Cdk-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdk-user

Reply via email to