OnDemand User Group
Support Forums => OD/WEK & JAVA API => Topic started by: ruudiculus on June 28, 2021, 02:29:48 AM
-
Hi all,
We have OnDemand server running on an AS400 machine. Our Java-applications that use ODWEK run on Linux-machines. Currently, each such Linux-machine (running JBoss) has an ODWEK installation. The coming year(s) we'll move to a cloud-based CI/CD environment, which makes it impossible to create ODWEK installations on specific machines. In order to land in that (to be) cloud-environment I took the approach to wrap the ODWEK .jar and its native libraries in an Uber-jar. (I could instead have taken a Docker-approach, but our current CI/CD-street doesn't support that).
In short my approach has been as follows:
- Install ODWEK 10.1 on a RedHat machine and apply update 10.1.0.6
- Use ldd to find out the dependencies of libars2wapi64.so, at least those that are not provided by the Linux distro.
- In my wrapper project I use maven to zip libgsk8cms_64.so, libgsk8km_64.so, libgsk8sys_64.so, libgsk8iccs_64.so, libgsk8ssl_64.so, and libars3wapi64.so together with the /applets and /locale folder.
- The wrapper project takes care of unpacking the .zip at runtime (to some jvm-tmp folder)
- The wrapper project takes care of loading the native libraries (in the above order), using System.load(). This way I don't need to bother anymore with setting LD_LIBRARY_PATH and java.library.path within Jboss.
- I use the Maven shade plugin to replace com/ibm/edms/od/ArsWWWInterface.class by a customized one that doesn't load ars3wapi64.so/ars3wapi32.so.
- This wrapper project has Google's gson-2.8.1 as dependency (so I figure its available on the classpath for the ODWEK library at runtime. At least I see no errors).
The artifact built from this wrapper-project is then used in one of our applications. I can confirm:
- the .zip gets unpacked successfully
- the native libraries get loaded successully
- connecting to the OnDemand-server works
- Obtaining all folders from the OD-server work
- Archiving documents works
HOWEVER: searching documents through odFolder.seach() always returns 0 documents (while the OD-client application lists > 0). I see no errors in the trace logging when searching, though I'm not a very experienced trace-log-reader :-). I wasn't able to upload my snippet of the tracelog; it is available for download https://drive.protonmail.com/urls/WPD5FHWGBC#rC9PCyIPCXIY (https://drive.protonmail.com/urls/WPD5FHWGBC#rC9PCyIPCXIY).
When I fall back to using the ODWEK-installation (exact same .so files, ODApi.jar etc.) that exists on the Linux-machine, the search works fine.
Does anyone here have an idea of what this wrapper may lack? On the native libraries side dependencies seem to be met and no exceptions seem to be raised, otherwise I would have expected a crashing application.
Regards,
-
Seeing a lot of 'Return Code 6'...
CsvGet***FromHit:Return arccs return code=6
Not sure what that means, but I would normally expect a zero.
-JD.