Sorry in advance if this has been asked before, I ...
# cfml-general
s
Sorry in advance if this has been asked before, I did some quick searching and could not find a successful search recipe. Anyway, I have a jar library that includes a dependency for a jar that CF includes, but a later version. This jar requires slf4f-api version 1.7.36, but CF includes an earlier version 1.7.12. I would prefer my dependency "somehow" be self-contained and not impact CF using .12 version that CF includes and uses. Is this possible?
m
I believe Mark Mandels Java Loader has been the most reliable cross platform way to work around that issue.
s
Thanks. I stopped using javaloader after CF included native support. I'll give it a try and see if it helps.
a
Did you just try the
javaSettings
thing in Application.cfc and check whether it just does what you need out of the box?
e
if you are on Lucee you can try wrapping your JAR into an OSGi Bundle to isolate its runtime. There are many helpers to do that, I even wrote one some time ago on ForgeBox. If you are on Adobe then you might be in a tight spot; the JavaLoader by Mark might work there.
💯 1
s
I did start with the native javasettings. I tried both loadColdFusionClassPath=false and true - different error messages but both failed. Moving on to the javaloader now...
I'm not using Lucee ATM, but I'll keep that in mind.
a
Cool, just checking.
s
Hmmm. I did get a little farther with the native JavaSettings. I found the sample code I am using had defined "StringDeserializer.class.getName()", where "StringDeserializer.getClass().getName()" seems to work better. Now the errors are: loadColdFusionClassPath = false: "Invalid value org.apache.kafka.common.serialization.StringDeserializer for configuration key.deserializer: Class org.apache.kafka.common.serialization.StringDeserializer could not be found." vs. loadColdFusionClassPath = true: "loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" the class loader coldfusion.runtime.java.JavaDynamicClassLoader @18815a8b (instance of coldfusion.runtime.java.JavaDynamicClassLoader, child of coldfusion.bootstrap.BootstrapClassLoader @695c938d coldfusion.bootstrap.BootstrapClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader coldfusion.bootstrap.BootstrapClassLoader @695c938d (instance of coldfusion.bootstrap.BootstrapClassLoader, child of org.apache.catalina.loader.ParallelWebappClassLoader @2b5f4d54 org.apache.catalina.loader.ParallelWebappClassLoader) for the method's defining class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type org/slf4j/ILoggerFactory used in the signature" I'm still experimenting...
And stranger. Removing "./lib/slf4j-api-1.7.36.jar" from the javasettings and setting loadColdFusionClassPath = true, now i get the same "Invalid value org.apache.kafka.common.serialization.StringDeserializer..." message. I think this might be solved if I was able to pass my StringDeserializer instance in the properties as opposed to the name of the instance for the kafka component to initiate.
For anyone curious, I resorted to what I would call a slimy hack. I added the Kafka jar with it's jar dependencies into a folder. I then added the folder as a virtual folder to [coldfusion path]/lib/[my new folder], I'm using docker desktop. Then I added this new folder to the coldfusion class path list, prior to the standard coldfusion [coldfusion]/lib folder. I'm assuming jars are searched in the order they are found in the class path list. It appears to be working for me. I never tried the JavaLoader method.