Enabling strict class loading mode for Connectors
Background
Historically, containers have provided certain common libraries that could be used by connectors utilizing the Connector SDK. Having these “shared” libraries allowed Connector archive files to be much smaller than otherwise. Although having shared libraries comes with some other benefits, it is ultimately unmanageable and makes connectors susceptible to breakage if and when shared libraries are updated/removed. These libraries may be updated or removed for various reasons, including: addressing security vulnerabilities, leveraging new features, compatibility with other libraries/frameworks, etc. Ultimately, the shared library model comes at a cost to the stability, security, and maintenance of containers and connectors alike.
In order to transition away from this model, Boomi will be introducing a new class loading mode for connectors. This new model will effectively cut off access to the shared libraries. This means that every connector must package all third party libraries (previously provided by the containers) that are required for successful process executions.
Strict Class Loading
In preparation for the container’s new class loading mode, Boomi is introducing a feature to assist Connector Developers in updating and testing their connectors. Boomi is exposing a strictClassLoading flag to the Connector’s Runtime Configuration file (connector-config.xml) that will function as a mechanism to opt-in to the new strict class loading mode ahead of forced mandate. This provides an interruption-free path for connectors to update and validate their connectors in the future mode.
Usage
Three steps are required to prepare a connector to run in strict class loading mode.
-
The first step is to package all the third party libraries that the connector needs to execute within the Connector archive file itself.
-
The second step is to update the Connector’s Runtime Configuration to indicate that it should be using the strict class loader.
-
The third step is to update the Connector SDK version to 2.23.2 or later.
Packaging
In order for a connector to run smoothly in strict class loading mode, it needs to ensure that all the execution time third party dependencies, needed by the connector, are packaged within the connector archive file. The connector must not assume that any such libraries will be provided by the runtime container during execution.
To avoid unintended functional changes, make sure that you package the same version of the dependencies that were provided by the container. You may update these dependencies, of course, but that may require further validation and possibly code changes to address deprecations or undesirable functional differences.
Go through the following checklist to ensure all the third party dependencies are included in the generated archive:
Packaging checklist
-
Review the dependencies declared in the build file
- Ensure your dependency scopes are correct
- For example:
- Maven dependencies scoped as runtime and provided are not packaged by default
- Gradle dependencies declared as implementation are not packaged by default
- For example:
- Ensure your dependency scopes are correct
-
Review your packaging configurations
- For Maven builds, ensure that you are not excluding or filtering out necessary dependencies in your Assembly Descriptor
- For Gradle builds, ensure that that you are not excluding necessary dependencies in your build.gradle file
-
Review your generated Connector archive file to ensure that all necessary dependencies are included.
You should not package the connector-sdk-api with your connector (regardless of if you enable strict class loading mode or not). Those classes and interfaces are always provided in the class loader running your connector code.
Previously provided Artifacts
The following is a list of artifacts that were previously included in the container but will not be accessible for your connector when operating in Strict mode:
| Group | Artifact | Current Version |
|---|---|---|
| com.boomi.regex | boomi-regex | 2.0.0 |
| com.boomi.restlet.util | boomi-restlet-util | 3.0.4 |
| com.boomi.security | boomi-security | 1.1.6 |
| com.boomi.util | boomi-json-util | 1.1.10 |
| com.boomi.util | boomi-util | 3.0.14 |
| com.boomi.util | common-lite | 1.1.0 |
| com.boomi.vault | container-api | 01.06.2 |
| com.fasterxml.jackson.core | jackson-annotations | 2.13.4 |
| com.fasterxml.jackson.core | jackson-core | 2.12.4 |
| com.fasterxml.jackson.core | jackson-databind | 2.12.4 |
| com.github.ben-manes.caffeine | caffeine | 2.8.6 |
| com.github.stephenc.jcip | jcip-annotations | 1.0-1 |
| com.google.errorprone | error_prone_annotations | 2.18.0 |
| com.google.protobuf | protobuf-java | 3.19.6 |
| com.healthmarketscience.common | common-util | 1.0.2 |
| com.healthmarketscience.sqlbuilder | sqlbuilder | 2.0.13 |
| com.nimbusds | nimbus-jose-jwt | 9.37.2 |
| com.noelios.restlet | com.noelios.restlet.ext.net | 1.0.11 |
| com.noelios.restlet | com.noelios.restlet | 1.0.11 |
| com.sun.activation | jakarta.activation | 2.0.0 |
| com.sun.istack | istack-commons-runtime | 3.0.8 |
| com.sun.org.apache.xml.internal | resolver | 20050927 |
| com.sun.xml.bind | jaxb-impl | 2.1.17 |
| com.sun.xml.fastinfoset | FastInfoset | 1.2.16 |
| com.sun.xml.messaging.saaj | saaj-impl | 1.3.2 |
| com.sun.xml.stream.buffer | streambuffer | 0.8 |
| com.sun.xml.ws | jaxws-rt | 2.1.5 |
| commons-codec | commons-codec | 1.15 |
| commons-lang | commons-lang | 2.5 |
| commons-logging | commons-logging | 1.1.1 |
| dom4j | dom4j | 1.6.1 |
| io.jsonwebtoken | jjwt | 0.9.0 |
| jakarta.activation | jakarta.activation-api | 1.2.1 |
| jakarta.xml.bind | jakarta.xml.bind-api | 2.3.2 |
| javax.activation | activation | 1.1 |
| javax.activation | javax.activation-api | 1.2.0 |
| javax.annotation | jsr250-api | 1 |
| javax.mail | 1.4.7 | |
| javax.xml.bind | jaxb-api | 2.3.1 |
| javax.xml.soap | saaj-api | 1.3 |
| javax.xml.ws | jaxws-api | 2.1-1 |
| jaxen | jaxen | 1.1 |
| jdom | jdom | 1 |
| org.apache.commons | commons-lang3 | 3.8.1 |
| org.apache.lucene | lucene-core | 3.5.0-boomi4 |
| org.apache.maven | maven-artifact | 3.6.3 |
| org.apache.oltu.oauth2 | org.apache.oltu.oauth2.client | 1.0.0 |
| org.apache.oltu.oauth2 | org.apache.oltu.oauth2.common | 1.0.0 |
| org.bouncycastle | bcmail-jdk15to18 | 1.7 |
| org.bouncycastle | bcmail-jdk16 | 1.45.boomi1 |
| org.bouncycastle | bcpg-jdk15to18 | 1.7 |
| org.bouncycastle | bcpg-jdk16 | 1.45 |
| org.bouncycastle | bcpkix-jdk15to18 | 1.7 |
| org.bouncycastle | bcprov-jdk15to18 | 1.7 |
| org.bouncycastle | bcprov-jdk16 | 1.45 |
| org.bouncycastle | bcutil-jdk15to18 | 1.7 |
| org.checkerframework | checker-qual | 3.33.0 |
| org.codehaus.plexus | plexus-utils | 3.2.1 |
| org.codehaus.woodstox | wstx-asl | 3.2.9 |
| org.glassfish.jaxb | jaxb-runtime | 2.3.2 |
| org.glassfish.jaxb | txw2 | 2.3.2 |
| org.hamcrest | hamcrest-core | 2.2 |
| org.hamcrest | hamcrest | 2.2 |
| org.json | json | 20131018 |
| org.jvnet.staxex | stax-ex | 1.2 |
| org.jvnet | mimepull | 1.3 |
| org.restlet | org.restlet | 1.0.11 |
| org.slf4j | slf4j-api | 1.7.30 |
| org.slf4j | slf4j-jdk14 | 1.7.30 |
| stax | stax-api | 1.0.1 |
If a com.boomi.Overrides file was previously used to selectively override artifacts, it will be ignored. Strict class loading mode supersedes the overrides configuration and expects the connector to package any and all third party libraries that it requires to function properly.
Update Configuration
If you are using Boomi’s Connector Gradle Plugin, the connector-config.xml file will automatically be generated when the strictClassLoading attribute set to true starting with version 0.5.1. This means upgrading your com.boomi.connector Gradle plugin to 0.5.1 will automatically opt you into strict class loading.
To opt into strict class loading mode, you will need to update the Connector’s Runtime Configuration file. You can do this manually by setting the strictClassLoading attribute to true and updating the SDK version to at least 2.23.2. For example:
<?xml version="1.0"?>
<GenericConnector sdkApiVersion="2.23.2" strictClassLoading="true">
<connectorClassName>com.boomi.connector.sample.SampleConnector</connectorClassName>
</GenericConnector>
The default for strictClassLoading is false, in which case it will run in whichever the default class loading mode the container is set to. In the future, this default mode will be set to strict.
Refer to the Connector SDK changelogs when updating your connector.
Testing and Validation
As you iterate through the previous steps, it is crucial that you test the connector. You should upload the connector to your Boomi Enterprise Platform account and test that all of the functionality is as expected. If you have set the strictClassLoading attribute to true but failed to include a required library you may encounter an error similar to:
Caused by: \<ThirdPartyClassName\> referenced from a method is not visible from class loader:com.boomi.connector.factory.ConnectorManager$ConnectorClassLoader@1052f423
Or:
java.lang.NoClassDefFoundError: <ThirdPartyClassName>
In preparation for this new class loading mode, Boomi has updated the Connector archive upload size limit to account for the increased size of Connectors. The new limit is set to 40MB. If your account requires an even larger limit to be approved, please contact your Boomi representative and they can assist you with this request.
