Author Topic: Wrapping ODWEK native libs in artifact  (Read 1433 times)

ruudiculus

  • Newbie
  • *
  • Posts: 1
    • View Profile
Wrapping ODWEK native libs in artifact
« 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.

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,
« Last Edit: June 28, 2021, 05:29:12 AM by ruudiculus »

Justin Derrick

  • IBM Content Manager OnDemand Consultant
  • Administrator
  • Hero Member
  • *****
  • Posts: 2229
  • CMOD Guru for hire...
    • View Profile
    • Tenacious Consulting
Re: Wrapping ODWEK native libs in artifact
« Reply #1 on: June 28, 2021, 10:43:16 AM »
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.
IBM CMOD Professional Services: http://TenaciousConsulting.com
Call:  +1-866-533-7742  or  eMail:  jd@justinderrick.com
IBM CMOD Wiki:  https://CMOD.wiki/
FREE IBM CMOD Education & Webinars:  https://CMOD.Training/

Interests: #AIX #Linux #Multiplatforms #DB2 #TSM #SP #Performance #Security #Audits #Customizing #Availability #HA #DR