Deploying JHSDK in a Java EE environment


[EDIT:  Ok. New info. JHSDK is not thread-safe. We’ve been very successful wrapping the CDI commands in java classes.  JHSDK is only appropriate for a Java SE environment.  Integrating CA Software Change Manager with a Java EE application]

Introduction

Deploying a web application that uses the JHSDK is not as simple as throwing a jar file in your lib directory. The JHSDK is a little different than other java libraries on three counts:

  1. it is a java wrapper for a C++ library. Allfusion Software Change Manager 7.x is a C++ application. The upcoming v12 release is a java application, so this C++ layer will go away [EDIT:  They did not update the JHSDK  to be pure java.  This prediction was incorrect]. But for now, we’re stuck with it.
  2. it is a bridge for communicating with another enterprise system. Harvest is a non-web, n-tier system for managing change on software and documents. It has a proprietary front controller that brokers requests from various Harvest clients.
    Harvest Architecture from \" width=
  3. it’s classes are not serializable, which presents problems when using it in Java EE environment

So, for your Java EE application to use JHSDK it must

  1. know where the C++ libraries reside
  2. run in an environment that has a Harvest client installed
  3. use serializable wrappers for the JHSDK classes that you need to persist

CA provides detailed documentation for setting up the environment in their Installation Guide. If you’re not accustomed to installing a Harvest client, this can be somewhat challenging. I found it very easy to deploy my web application to my local windows installation of Glassfish because I already have a working Harvest client installed; however, I worked for nearly three weeks with my Sun admin, Harvest admin, and CA Support to configure our development Solaris environment. We had never used a Harvest client on Solaris before, and you know how UNIX environments are: SOME ASSEMBLY REQUIRED.

Windows Deployment

This is an account of my deployment to a Java EE platform on Windows

OS: Windows XP SP2

Application Server: Sun Java System Application Server 9.0 Update 1 (glassfish v2 ur1)

Harvest: AllFusion Harvest Change Manager 7.0

I didn’t have to set up the Harvest Client because it was already done, so I won’t comment on that.

In Windows, there are two files that Glassfish needs to know about: jhsdk.jar and JHSDK.dll. Both of these files need to be your Glassfish’s path.

You can put them in

GLASSFISH_HOME\lib

or

GLASSFISH_HOME\domains\domain1\lib

If you deploy the jhsdk.jar file without the JHSDK.dll file, then you will receive the following error:

java.lang.UnsatisfiedLinkError: no JHSDK in java.library.path

At this point in the development process, my application provides a list of versions for a particular Harvest Package. The JCaVersion class does not implement java.io.Serialiable, so I was not able to bind it to my JSF component. So I wrote my own version of JCaVersion. I looped through my array of JCaVersions (which is returned from JCaPackage getVersionList()), and built an array of MyVersion instances with the same data. Then I could bind my array of MyVersion instances to my JSF component.

Finally, I deployed my WAR file and I was ready to go. I was so excited. WOW! That was easy! I’ll just deploy it on the Solaris box and I’ll be ready for show and tell. And……PRESTO!!! 3 weeks, 5 support emails to CA Support, a chat fight with my Sun admin, 50 meetings with my Harvest Admin later, it’s working!

Solaris Deployment

OS: Solaris 9

Application Server: Sun Java System Application Server 9.0 Update 1 (glassfish v2 ur1)

Harvest: AllFusion Harvest Change Manager 7.0

The first issue that arose was that the client was not fully installed on the Solaris box. Our app server and the Harvest server happen to be installed on the same machine, so the client should have been installed and available already. The key command-line utilities were there, and the HSDK and JHSDK are supposed to come with the command-line utilities, but they didn’t. So, we reinstalled the command-line utilities, and that set up all the files and directories we were needing.

Once we had the client installed, we needed to configure an environment for using the JHSDK. CA’s installation guide is pretty explicit, but I had trouble using it…perhaps because I’m not really that skilled with Solaris. Here’s what my env looks like:

JAVA_HOME=/usr/java
HARVESTHOME=/xxx/ca/harvest
CACRYPTINI=/opt/CA/CAcrypto/cacrypt.ini
CACRYPTDIR=/opt/CA/CAcrypto
DVHOME=/xxx/ca/pec/graphics/sun4_solaris
RTARCH=sun4_solaris
RTARCH_UC=SUN4_SOLARIS
RTHOME=/xxx/ca/pec
_app=/xxx/ca/pec/app-defaults
export JAVA_HOME HARVESTHOME CACRYPTDIR CACRYPTINI
export DVHOME RTARCH RTARCH_UC RTHOME _app
LD_LIBRARY_PATH=${CACRYPTDIR}:${RTHOME}/lib/sun4_solaris:${RTHOME}/graphics/sun4_solaris/lib:/usr/lib
LD_LIBRARY_PATH=${HARVESTHOME}/lib:${HARVESTHOME}/HSDK/lib:${HARVESTHOME}/JHSDK/lib:$LD_LIBRARY_PATH
PATH=${RTHOME}/bin:${HARVESTHOME}/bin:$PATH
export LD_LIBRARY_PATH PATH

I recommend following CA’s advice to test your environment with the sample JHSDK application as detailed in the Installation Guide. This will tell you whether or not you were successful.

The next step is to configure Glassfish. This is where it gets weird. Even though we’ve setup all this path info in the environment, we have to do it again in Glassfish. My guess as to why? The Java EE environment needs to know the paths to the native libs so the when the JHSDK classes are called, then can know where to find their C++ peers. The user environment needs to know the paths so that when when one of the native C++ classes is called, it knows where they are and where Harvest is. Again, that’s my best guess. If I learn different, or if you know different please tell me and I will give an update.

So here’s what my Native Library Path Suffix in Glassfish looks like:

:/xxx/ca/harvest/lib:/xxx/ca/harvest/HSDK/lib:/xxx/ca/harvest/JHSDK/lib:/opt/CA/CAcrypto:/xxx/ca/pec/lib/sun4_solaris:/xxx/ca/pec/graphics/sun4_solaris/lib:/usr/lib

Here’s what my Classpath Suffix looks like:

:/usr/java/jre/lib:/usr/java/lib:/xxx/ca/harvest/lib:/xxx/ca/harvest/HSDK/lib:/xxx/ca/harvest/JHSDK/lib:/xxx/ca/harvest/JHSDK/lib/jhsdk.jar

Look for future posts here on my use of JHSDK in my Java EE application. The journey has only begun…

Advertisements

3 thoughts on “Deploying JHSDK in a Java EE environment

  1. Ok. New info. JHSDK is not thread-safe. You either need to use synchronization or drop JHSDK althogether and wrap the Command-line Interface. SOA Integration Bridge is also a topic of interest for integration with CA SCM r12.

  2. Hi,
    Since you seem to have knocked on quite a number of doors to get this deployment going.. i was wondering if you had any issues with JHSDK running on JRE 1.6?

    Regards,
    /Suranga

    • No, but ultimately we could not use JHSDK with Glassfish….not threadsafe. Instead, we building our own threadsafe wrappers for the CLI and called it good…but we are struggling with some scalability issues with that. No answers yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s