Can IS Java service use a different version JAR than one provided by IS?

, ,
1

I use webMethods Integration Server version 10.1 on-premise (extended support). As described here, I wrote a Java service that uses external JARs. For this, I added JARs to the package’s code/jars folder.

The code compiles but fails at runtime with this JAR version conflict error

Could not run 'deliverDataToAzureBlobStorageService'
java.lang.reflect.InvocationTargetException: Package versions: jackson-annotations=2.10.1, jackson-core=2.10.1, jackson-databind=2.10.1, jackson-dataformat-xml=unknown, jackson-datatype-jsr310=unknown, azure-core=1.22.0, Troubleshooting version conflicts: https://aka.ms/azsdk/java/dependency/troubleshoot

Any ideas how to resolve it?

The problem seems that my custom Java service requires a different version of ‘Jackson’ JARs (used for JSON parsing) than those provided internally by IS 10.1. The new JARs in the package code/jar folder are Jackson version 2.x. But the IS ‘About’ page shows IS uses Jackson JAR version 1.8.
/opt/SoftwareAG101/IntegrationServer/lib/jars/jackson-coreutils-1.8.jar

How can I make my package’s Java code use Jackson version 2.x (the JARs I uploaded into the package code/jars folder), and not use Jackson version 1.8, while leaving the rest of IS unaffected?

2

@Sonam_Chauhan ,
You can use a package classloader . You would need to write access to the file system where IS is installed though, From the admin guide
https://documentation.softwareag.com/webmethods/integration_server/pie10-5/10-5_Integration_Server_Administrators_Guide.pdf - page 685

You might want to use a newer version of a class that exists in the package directory, rather than the version the Integration Server class loader will access.
For the package class loader to have access to class you want to load, the jar files containing the class you want load must exist in this directory:
Integration Server_directory \instances\instance_name\packages\packageName\code\jars directory.
To configure Integration Server to use a package class loader

  1. Navigate to the Integration Server_directory \instances\instance_name\packages\packageName
    directory, where packageName is the name of the package that has the jar files that you want to
    load.
  2. Add the following property to the manifest.v3 file:
    package
  3. Reload the package.

That should work for you
-NP

1 Like
3

Thanks very much Nagendra. Your suggestion worked after an initial glitch. I am now struggling with a certificate validation error (‘General OpenSslEngine problem’)

Your suggestion of setting the package classloader property to “package” got me past the old error. However, I hit a new ‘loader constraint violation’ problem below.

Could not run 'deliverDataToAzureBlobStorageService'
java.lang.reflect.InvocationTargetException: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" 
the class loader (instance of com/wm/app/b2b/server/PackageClassLoader) of the current class, org/slf4j/LoggerFactory, 
and the class loader (instance of java/net/URLClassLoader) for the method's defining class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type org/slf4j/ILoggerFactory used in the signature

Thankfully, I could wing it after coming across this article. It suggested installing slf4j-jdk14-1.7.32.jar (an unlisted dependency on top of the slf4j-api-1.7.32 JAR dependency Maven had calculated). Adding the JAR resolved a sort of crazy circular dependency in the slf4j package.

But running the service now returns a ‘General OpenSslEngine problem’

Could not run 'deliverDataToAzureBlobStorageService'
reactor.core.Exceptions$ReactiveException: javax.net.ssl.SSLHandshakeException: General OpenSslEngine problem

The error log stack trace indicates code in the io.netty. package tried to open a connection to https://<instance>.blob.core.windows.net/inbound but did not trust the Microsoft issued certificate. How to make it work is now again a mystery.

sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
at sun.security.validator.Validator.validate(Validator.java:262)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
at io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientContext.java:234)
at io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertificateVerifier.verify(ReferenceCountedOpenSslContext.java:748)
at io.netty.internal.tcnative.CertificateVerifierTask.runTask(CertificateVerifierTask.java:36)
at io.netty.internal.tcnative.SSLTask.run(SSLTask.java:48)
at io.netty.internal.tcnative.SSLTask.run(SSLTask.java:42)
at io.netty.handler.ssl.ReferenceCountedOpenSslEngine$TaskDecorator.run(ReferenceCountedOpenSslEngine.java:1455)
at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1548)
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1394)
at io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1246)
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1286)
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:507)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:446)

The IS has a dummy truststore and these extended settings, so it should trust any certificate.

watt.security.cert.wmChainVerifier.trustByDefault=true
watt.server.ssl.trustStoreAlias=

I tested a connection from pub.client:http on that IS – it connected to the https://<instance>.blob.core.windows.net/inbound website without a problem.

Another option is delivering to **http**://<instance>.blob.core.windows.net/inbound (no SSL), but this is not enabled.

Any thoughts on the certificate validation error (‘General OpenSslEngine problem’)?

4

I’m not an SSL/Azure expert so please take this with a pinch ( only a pinch ? :slight_smile: ) of salt. This is only based on my observation as a java developer.
In general when SSL is involved , you need to have the truststore setup from a client , I would suggest you go through the Azure documentation which mentions importing the microsoft truststore/certificate. But IS watt property is set to ignore truststore, so I’m not too sure.
My general suggestion would be to create a new topic with this error, that way it is likely to receive more attention , since this topic is already solved with a different title.

-NP

5

Thanks Nagendra - I figured out the problem: nirvana.* config directives in custom_wrapper.conf were redirecting the keystore/truststore used by Java code away from IS_DEFAULT_TRUSTSTORE. Removing those directives resolved my problem. The code is now working. I’ll be updating the parent forum post with my overall result

6

Excellent! Glad to know you figured it out. Please consider extracting the contents into a knowledge base article , will be very helpful for someone going down the same road.

-NP

7

General note: it is disappointing that things seem to be going backwards in terms of interactions with applications/systems. The need to use a “client library” for a specific system is a throwback to old ways. The use of a library has all of the nasty lib dependency bloat that we’ve largely been able to get away from in the past decade. Who hasn’t encountered “I want to use a method in class X, but doing so requires importing a whole pile of jars.” :frowning:

Interestingly, you went with the client-library approach rather than the API approach. I would have avoided the library like the plague. :slight_smile: Glad you’ve been able to get a working path.

1 Like
8

Well put Rob, and you are right. I put down my thoughts here

Thankfully I was able to escape dependency hell - this time!

9

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.