Shared Java codes in WM

Hi All,

Please help. I have packages structure below. How can package2/javaService2/javaMethod2 invoke package1/javaUtil/javaMethod1 given that 1) jcode ran fine (no errors) 2) javaService1/goodJavaService can invoke javaUtil/javaMethod1 and 3) javaUtil/javaMethod1 is just a regular Java method (not service in WM meaning)?

— javaService1 (folder)
------ goodJavaService (Java service)
— javaUtil (folder)
------ javaMethod1 (shared Java method)

— javaService2 (folder)
----- javaMethod2 (Java service)

Thanks in advance.


Sorry forgot to add that when I’d tested the codes I received: java.lang.reflect.InvocationTargetException:javaUtil/javaMethod1.



you can encapsulate this shared code as a java service and have it called by both packages.

Make sure you’ve specified the correct complete classname when referencing javaMethod1. The best way to confirm is to look at the Java source in the [package]\code\source directory. Make sure your method is declared as public.

Thanks Adnan. That’d be too easy. I thought of doing that but the constraints of being a Java service (like having the IData only in the signature, having to do Service.doInvoke() within the Java codes for this case, etc) don’t serve me well. Also, it’s a util package so the kind of processing it does is very generic and some time doesn’t fit to be a Java service (for ex., getting a value out of the pipeline).

Thanks Rob. That’s the first thing I did.

  1. The fact that the codes compiled w/o errors tells me that package2 sees package1/javaUtil. But when it comes to running in the IS, it’s not quite true.
  2. goodJavaService can invoke javaUtil.javaMethod1.
  3. When I copied the javaUtil folder to package2, it works fine.

so…I came to the conclusion that Java services can’t “see” regular Java codes from a different package. I’ll try to verify this but in the mean time, any contrary opinions?

The only thing that I haven’t checked out (and don’t know how yet) is to play with the classpath of the IS. Any suggestions?


Server class path should solve your problem but is generally not recommended, but u might be able to solve this issue using package dependencies. You can set these from Developer by doing right click and select Open on the package. Enter the package name and you can use . for the version.


MyPackage1 dependent on MySharedPackage
services that reference utils.jar

MyPackage2 dependent on MySharedPackage
services that reference utils.jar

so no server classpath mods, and it allows you to install your packages via package replication.