DFC App works in Eclipse but fails in runnable Fat Jar

Summary
We have a DFC app that was written for Documentum 5.3. We have updated the DFC libraries to version 6.7 and recompiled. The code runs successfully in the IDE, but when we create a runnable jar file it fails.

Details
When upgrading to DFC 6.7 we had to comment out an import statement and change one line of code:

// Commented this import statement
//import com.documentum.operations.DfImportOperation;

. . .

IDfClientX clientX = null;
. . .

IDfImportOperation importOperation = null;

// Replaced this line
//importOperation = new DfImportOperation();
// with this line
importOperation = clientX.getImportOperation();

I can provide more details of the code if needed, but I'm pretty sure there is nothing wrong with the code since it works in the IDE.

We are creating an executable jar using the Build Fat Jar plugin for Eclipse. Running the executable jar fails on the new line of code "importOperation = clientX.getImportOperation();" with this exception:

com.documentum.fc.common.DfRuntimeException: IO Exception while reading operations definitions from jar file String index out of range: -1
        at com.documentum.operations.impl.config.reader.JarReader.listFiles(JarReader.java:133)
        at com.documentum.operations.impl.config.reader.JarReader.loadConfigFiles(JarReader.java:83)
        at com.documentum.services.config.impl.ConfigService.initialiseApp(Unknown Source)
        at com.documentum.services.config.impl.ConfigService.initialiseApp(Unknown Source)
        at com.documentum.services.config.impl.ConfigService.loadConfig(Unknown Source)
        at com.documentum.operations.impl.config.ConfigManager.initializeConfigService(ConfigManager.java:438)
        at com.documentum.operations.impl.config.ConfigManager.newConfigService(ConfigManager.java:335)
        at com.documentum.operations.impl.config.ConfigManager.loadDefaultConfigurations(ConfigManager.java:310)
        at com.documentum.operations.impl.config.ConfigManager.<init>(ConfigManager.java:40)
        at com.documentum.operations.impl.config.ConfigManager.getInstance(ConfigManager.java:46)
        at com.documentum.operations.impl.DfOperationManager.getOperation(DfOperationManager.java:25)
        at com.documentum.com.DfClientX.getNewOperation(DfClientX.java:638)
        at com.documentum.com.DfClientX.getImportOperation(DfClientX.java:644)
        at com.mycompany.DocOps.DocOps.importDocumentInherited(DocOps.java:898)
        at com.mycompany.BulkImport.BulkImportInherited.importFileBulk(BulkImportInherited.java:103)
        at com.mycompany.BulkImport.BulkImportInherited.main(BulkImportInherited.java:50)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at com.simontuffs.onejar.Boot.run(Boot.java:306)
        at com.simontuffs.onejar.Boot.main(Boot.java:159)

It seems to me that the problem lies either with the way I am creating the fat jar or the runtime environment, but I haven't been able to figure out what. I'm hoping that someone has run into this and has some ideas for me.

Thanks,

Jim Anderson

Find more posts tagged with

Comments

aflowers001

Does sound like it is a packaging issue. Basically dfc.jar hasa slew of XML config files that are used by the operations to determine how they carry out what they need to do, under the com\documentum\operations\1\config\ path.

I'm guessing that these are not there hence the JarReader error loading config/listing files.

jimazing

Thanks Andy. If it is indeed something in the dfc.jar, why would it behave differently in the IDE than it does in my jar? They are both referencing the same dfc.jar. Any ideas of things I can try or check for?

aflowers001

It is possibly the fat java plug in which attempts to produce one 'mega' jar from many distinct ones.

Check if the files expected are still in the mega jar and where they are. Sounds like packaging in this manner is confusing DFC.

Might be worth running it from the command line with java -verbose:class whihc will give some idea about what classes are being loaded, but unfortunately quite probably won't help with your particular issue.

Have you tried deploying as a standard Java app with many jars, which would be the same as the IDE uses.

You can have the main jar have a manifest referencing the required other jar files such that the classpath isn't needed and you can put them all in the same location and just execute the main jar.

jimazing

Andy,
Thanks for hanging with me. I did the -verbose. Wow! what a lot of output! As you predicted, it didn't really help find a resolution though.

Interestingly, I went back to the original 5.3 DFC and original code. Compiled and ran it successfully Jarred with the Fat Jar plugin and the jar works correctly. I then made the code adjustments just like I had in 6.7. This also worked both ways.

Updated DFC and adjusted the build path to fit the new list of jars in Documentum\Shared. Just like before, it works in the IDE, but no longer works as a runnable jar file. The only piece that changed was switching out the DFC.