Hi all,
default WM9.7 JAR for Apache commons-codec is v1.3.
Unfortunately, I need to use some commons-codec function that have been created in Apache commons-codec v1.4 and is not available in default loaded commons-codecin WM (actually this is another JAR I’ve loaded that needs it).
I’ve placed commons-codec-1.9.jar in IntegrationServer/lib/jars and restarted the IS.
In the about page, I can see the jar listed as loaded.
By the way, I can also see:
/common/lib/ext/commons-codec.jar and /WS-Stack/lib/shared/commons-codec-1.3.0.jar
I’ve also placed commons-codec-1.9.jar in my Designer package code/jars so imports in my java code can be resolved properly.
However, if my java code uses method encodeBase64URLSafeString(byte) (only available since commons-codec v1.4) it cannot compile and I get error message:
error: cannot find symbol
symbol: method encodeBase64URLSafeString(byte)
location: class Base64
It looks as if commons-codec v1.3 takes precedence over any more recent version of this JAR.
I’ve also tried by “package locally” loading the v1.9 JAR by placing it on the IS /lib and reloading my package but same result 
Has anyone ever faced such a need to load a newer version for commons-codec ?
Hi Julien ,
Please place the jars inside the (package_name)/code/jars folder and try.
IS Package Class Loaders#
Separate package class loaders are created and associated with every Integration Server package that is loaded by the package manager. The parent of every package class loader is the IS server class loader.
This article mentions about the Integration Server Class loading.
https://techcommunity.softwareag.com/pwiki/-/wiki/Main/webMethods+Integration+Server+Class-Loading
Hi,
I’ve actually placed the jar in both /lib and /code/jars in the IS and I’ve reloaded the package.
It does not compile though (same error message).
More “interesting” as I did not check before: it does not show in the server classpath at all.
But the other JAR that is in /lib does not show either and everything compiles properly with it.
Hi,
this is a question of the order in which the jars are loaded.
Usually the first jar loaded in which the class is defined is used.
Referring to the Article Rakesh has mentioned in this thread forcing a newer version of an already existing jar to be loaded will only be possible when using the PREPEND_CLASSES parameter in the startup script.
Regards,
Holger
Hi,
I had the same understanding/fear since commons-codec seems to be actually loaded at startup in v1.3.
What I fear is that if I load v1.9 of commons-codec through PREPENDCLASSES at the IS level (IS Server Class Loader), then it will be used for the whole IS, including the apache server and WS-Stack and so on; this could create other issues to some other places that could only be noticed later.
Is there really no way to load v1.9 of commons-codec with local visibility only at some package level while the other places of the IS would still see v1.3 (default one) ?
Or… is there a way to upgrade the IS to use a more recent version of commons-codec as default?
From my understanding, the fact that this v1.3 JAR is loaded is due to default IS behaviour as it loads through:/common/lib/ext/commons-codec.jar and /WS-Stack/lib/shared/commons-codec-1.3.0.jar
Both locations seems to be default webMethods locations.
Hi Julien,
as the ClassLoaders are inheriting from their parents it will not be possible to load the newer jar except by using PREPENDCLASSES.
For clarification you should open an incident in Empower.
Please update this thread with the outcome.
Additionally you can open a feature request in brainstorm requesting an update of the jar.
Regards,
Holger
Hi,
I understand.
We’ve finally found a solution (not super clear, but at least it works): since, luckily, this is an open source library, we’ve gotten the source code from apache, changed the package names to no longer be org.apache.commons.* but to me Myorg.apache.commons.*, then we’ve recompiled and produced a new JAR.
This allows to no longer have conflicts between default 1.3 being loaded at IS startup and v1.10. We only needed to update our import statements on our code.
This also works with external libraries linked to commons-codec as long as these are open source libraries and you can get the code and update the import statements.
Not the cleanest solution but this is still a workaround.