Apache Commons IO Library: Multiple Versions

Hello everybody,

I am developing an Ignition module that uses the Apache Commons IO library, specifically v2.0+ of the library. Most of the functionality I need works fine, but I am getting the following error regularly:

java.lang.NoSuchMethodError: org.apache.commons.io.IOUtils.closeQuietly(Ljava/io/Closeable;)V

This particular overload of IOUtils.closeQuietly is only present in v2.0+ of the Commons IO library. After some debugging I found that the Ignition SDK uses a pre-2.0 version of the library, located in ignition-commons.jar. Having multiple versions of the library, and being unable to point my module code to the v2.0+ version, appears to be the source of my problems.

I’ve tried unpacking the commons-io-2.0.1.jar and re-packaging it along with my code in my module jar file, and I still get the same error.

If anyone has a suggestion on how to get this how to work I’d love to hear it.

I can’t see an easy solution to this. We load Apache Commons IO 1.4 in a classloader way above you along with the rest of the ignition-common stuff.

The path of least resistance is to stop using 2.0 and just use the 1.4 we provide. There’s also a chance we’ll upgrade the version of some of the libraries we include (google-collections which is now guava, apache io commons, etc…) for 7.4.

We’re using the commons io library for its tailing functionality, which is only available on v2.0+. Have you guys tested the SDK with v2.0?

We haven’t yet.

Our work around is to download the source, change the package name, and recompile.

That just seems so wrong. Hope you have good version control procedures. I can see so many ways this can bite you back.

Yeah, I would say that the best course of action in cases like these is to just request that we update the libraries.

However, there’s also the argument to be made that we should tweak the way the module loading works, to make the module class loading system work a bit more like tomcat’s- inverting the normal classloading model to look down first before going up. That way, the module author could use libraries provided by Ignition, or could supply their own. We’ll have to look at the implications of this, but I think it makes sense.

Regards,

I wasn’t going to suggest this, but good job! :slight_smile:

Spoken like a true field tech turned developer. :smiling_imp:

Obviously, I understand the drawbacks of this method, but when there is a timeline coming up, and there seems to be no other resolve, sometimes we have to do things that aren’t ideal. The ideal situation would be to have the io package in Ignition upgraded, and once it is upgraded, obviously our module would get switched to use the updated library. But as a “Field Tech Turned Developer”, I have the common sense to solve problems and not complain and wait for others to do it for me.

:laughing:
Thanks Kyle, made me smile.