David1
Occasional Observer

Connecting to a firstspirit server from an spring application inside a docker container

Jump to solution

Hello!

I have the following problem:

I am developing an spring application which uses the firstspirit-isolated-runtime as a 3rd party dependency. The version i am using for development right now is the version 5.2.230607.

Inside that spring application i am trying to establish a connection to the firstspirit server using the ConnectionManager.getConnection method from the Firstspirit-API. This setup works fine when testing out my application locally on my IDE (IntelliJ 2024.2.3) and trying to connect to the firstspirit server. My goal is to deploy the application on a docker container and run the spring application from there. However when i try to establish a connection to the Firstspirit-Server from that container i get the following error: 

java.lang.SecurityException: Access denied to de.espirit.firstspirit.store.access.AbstractSecurityManager! Class de.espirit.firstspirit.access.DefaultConnectionFactory has missing or invalid signature!


My idea is that is that the spring classloader is the problem here and can not load the correct Signature. My Question is how can i build my spring application so that i can use the firstspirit libraries with the correct signature. I already verfied that the network settings inside my docker container are correct. Is there a recommended way to build my spring application to establish a connection to firstspirit using the fs-isolated-runtime library.

 

Best regards,
David

0 Kudos
1 Solution

Accepted Solutions
Windmüller
Crownpeak employee

I just remembered that I had the exact same issue over seven years ago. Please see Spring Boot #8704 for details and a possible solution.

View solution in original post

5 Replies
Windmüller
Crownpeak employee

How exactly do you package your application? The runtime jar has to be unmodified because otherwise the signature will be invalid.

0 Kudos

I am using gradle and the corrisponding gradle spring plugins to package my application with the bootJar Task. This results in the following folder structure:

BOOT-INF

      ---------> classes

      ---------> lib -> This is where the isolated-runtime jar resides with the SIgnature present after unzipping

META-INF

      ---------> services

      ---------> BOOT.SF

      ---------> MANIFEST.MF

org

     ----------> To my understanding classes related for the spring classloader

Plugins used:

    id 'org.springframework.boot' version '3.3.2'
    id 'io.spring.dependency-management' version '1.1.4'

I did no modifications to the Spring related Tasks like bootJar as left them as is. 

The library is included with the following Dependency Scope:

implementation group: 'de.espirit.firstspirit', name: 'fs-isolated-runtime', version: 'Some Version'

 

0 Kudos
Windmüller
Crownpeak employee

I just remembered that I had the exact same issue over seven years ago. Please see Spring Boot #8704 for details and a possible solution.

That link was really helpful!

I got my setup working with the following configuration:

bootJar{
    requiresUnpack('**/fs-isolated-runtime-*.jar')
}

 

Thank you for your help 🙂.

hbarthel
New Responder

We are using a different approach since years now and the idea is, to not deliver the fs-isolated-runtime.jar within the SpringBoot application, but it resides in the file system of the server instead.

In build.gradle we define the following:

bootJar {
    archiveFileName = 'app.jar'
    // enables 'loader.path' system property for specifying location of FirstSpirit jar
    manifest {
        attributes 'Main-Class': 'org.springframework.boot.loader.launch.PropertiesLauncher'
    }
}

For Maven it looks like so in pom.xml:

<plugin>
    <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
        <configuration>
            <!-- enables 'loader.path' system property for specifying location of FirstSpirit jar -->
            <layout>ZIP</layout>
...
        </configuration>
    </plugin>

And we start it like so:

java -Dloader.path=path/to/fs-isolated-runtime-5.2.240312.jar -jar app.jar

 

Maybe this helps somebody out.

Cheers, Heiko