How to fix OGGV-80010 “Could not get CredentialStore instance.”

If you are standing up the Oracle GoldenGate Veridata 23c command line (vericom.sh) on JDK 17 and you keep slamming into this wall:

OGGV-80010: Could not get CredentialStore instance

… and no amount of recreating the wallet, fixing permissions, or editing the config makes it go away this post is for you. The error message is a red herring. It has nothing to do with your wallet file, your permissions, or your jps-config-jse.xml. The real cause is a missing JAXB class on JDK 17, hidden behind a small bug in the launcher script. Here is the full diagnosis and the one-line fix.

vericom.sh builds a Java classpath from libs/*.jar and then starts the JVM with java -jar — which ignores that classpath. On JDK 17 (which no longer bundles JAXB), javax.xml.bind.JAXBException never loads, Oracle’s OPSS layer can’t parse its config, and every credential-store operation dies with OGGV-80010.

The fix: in vericom.sh, change -jar "${JAR_PATH}" to -cp "${JAR_PATH}${CLASSPATH}" com.goldengate.veridata.VericomNextGen.

The symptom

The goal was simple: create a credential store and an alias so Veridata jobs run without typing a password every time. Both setup commands failed:

$ ./vericom.sh -addCredentialStore -u admin

Credential store folder '/data/oggvd/cli/config'

OGGV-80077: Credential store already exist at provided location.

$ ./vericom.sh -createAlias myadmin -u admin

File exist status:::true

OGGV-80010: Could not get CredentialStore instance

Two different errors, both misleading:

Error Code	Message	Root Cause
OGGV-80077	Credential store already exists at provided location.	It checks for the jps-config-jse.xml file only — not an actual wallet (cwallet.sso). No wallet existed.
OGGV-80010	Could not get CredentialStore instance.	Generic wrapper hiding java.lang.ClassNotFoundException: javax.xml.bind.JAXBException — JAXB JARs not on classpath because -jar ignores CLASSPATH.
OGGV-20006	Unrecognized command line flag.	Invalid flag used (e.g., -generatePassword, -dropCredentialStore). Correct flags: -addCredentialStore, -deleteCredentialStore, -createAlias.
OGGV-20051	Veridata username is required.	Missing -u or -user flag in the command.
OGGV-20053	Authorization failed while running Command-Line Utilities.	Wrong password entered (or blank/Enter pressed at prompt).

Chasing red herrings (so you don’t have to)

OGGV-80010 points nowhere, so it’s tempting to try everything. Here is what does not fix it:

What you might suspect	How to check	Verdict
A hung process holding a lock	ps -ef | grep -i veri	Not it — no stale CLI process.
Permissions / ownership	id & ls -la config/	Not it — all oracle:oinstall, dir writable.
Missing / corrupt wallet	find . -name 'cwallet.sso*'	Not it — recreating doesn't help.
Broken jps-config-jse.xml	diff against a working domain	Not it — config is byte-for-byte identical to a working one.
JAXB JARs not on classpath	Check log: NoClassDefFoundError: javax/xml/bind/JAXBException	Root cause — -jar flag makes Java ignore CLASSPATH

The key realization: a different Veridata domain on the same box (the server) had a working credential store using the exact same config form. So the mechanism works on JDK 17 — the problem had to be runtime, not configuration. Time to read the log.

The breakthrough: read the stack trace

The CLI writes to <domain>/veridata/logs/vericom.log. The terse OGGV-80010 unwraps into a very clear root cause:

OGGV-80010: Could not get CredentialStore instance

Caused by: oracle.security.opss.config.persistence.exception.ConfigurationPersistenceRTException:

           java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException

        at ...JpsConfigurationPMetaFactoryImpl.<init>

        at oracle.security.jps.JpsStartup.start(JpsStartup.java:228)

Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException

Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException

Root cause: OPSS needs JAXB (javax.xml.bind) to parse jps-config-jse.xml. JAXB was removed from the JDK in Java 11, and this box runs JDK 17, so the class has to come from a jar on the classpath. It wasn’t being loaded.

But the JAXB jar IS there… why isn’t it loaded?

This is the twist. jaxb-api-2.3.1.jar (which contains javax.xml.bind.JAXBException) was sitting right there in libs/. The problem was how the launcher starts Java. Look at vericom.sh:

# vericom.sh builds a full classpath from every jar in libs/ ...

_CLASSPATH=

for i in `ls ${APP_PATH}/libs/*.jar`; do _CLASSPATH=${_CLASSPATH}:${i}; done

export CLASSPATH=$_CLASSPATH

...

# ... then launches the JVM like this:

$JAVA_PATH $JAVA_OPTS ... -jar "${JAR_PATH}" $params

The bug in one sentence: java -jar completely ignores $CLASSPATH and -cp. When you launch with -jar, the JVM uses only the Class-Path declared inside that jar’s META-INF/MANIFEST.MF which doesn’t list jaxb-api. So the carefully-built classpath (with JAXB in it) is thrown away.

That one mistake explains every symptom. It was never the wallet, the permissions, or the config just an opaque error code sitting on top of a plain classpath bug.

The fix

Switch the launch from -jar to -cp with an explicit main class. The main class — com.goldengate.veridata.VericomNextGen — comes straight from the stack trace.

# 1. Back up the launcher

cp -p /data/oggvd/cli/bin/vericom.sh /data/oggvd/cli/bin/vericom.sh.bak

# 2. Replace -jar with -cp + main class

sed -i 's|-jar "${JAR_PATH}"|-cp "${JAR_PATH}${CLASSPATH}" com.goldengate.veridata.VericomNextGen|' \

    /data/oggvd/cli/bin/vericom.sh

Before and after of the final line:

BEFORE (classpath ignored):

... -Dveridata.cfg.loc=$CONFIG_LOC -jar "${JAR_PATH}" $params

AFTER  (classpath honored, JAXB loads):

... -Dveridata.cfg.loc=$CONFIG_LOC -cp "${JAR_PATH}${CLASSPATH}" com.goldengate.veridata.VericomNextGen $params

Because ${CLASSPATH} already starts with a colon, "${JAR_PATH}${CLASSPATH}" expands to the client jar followed by every jar in libs/ — including jaxb-api-2.3.1.jar. The JVM now finds javax.xml.bind.JAXBException, OPSS parses the config, and the wallet works.

Verification

The same commands that used to fail now succeed:

$ ./vericom.sh -createAlias myadmin -u admin

Successfully created alias 'myadmin' for user.

$ ls -la /data/oggvd/cli/config/cwallet.sso

-rw------- 1 oracle oinstall 383 Jun 22 11:11 .../cwallet.sso   # wallet created

$ ./vericom.sh -j DEV -userAlias myadmin

Veridata job submitted successfully!  Run ID: 1405/0/0          # no password prompt

Bonus: actually running jobs passwordless

One last gotcha. If you run a job with -u admin, it still prompts for a password  that flag means “authenticate interactively.” The whole point of the alias is to avoid that. Use -userAlias instead:

Flag	Behaviour
-u admin	Prompts for a password every run.
-userAlias myadmin	Reads the stored credential from the wallet — no prompt. Use this in crontab.

./vericom.sh -j DEV -userAlias myadmin

./vericom.sh -userAlias myadmin -monitorStats <runId>

Lessons learned

• OGGV-80010 is a wrapper. Always read vericom.log for the real Caused by: chain before touching wallets or config.
• JDK 11+ removed JAXB. Any older Java tool that parses XML via javax.xml.bind needs the JAXB jars explicitly on the classpath.
• java -jar ignores $CLASSPATH and -cp. If a launcher builds a classpath but starts with -jar, that classpath is dead code.
• The drop flag is -deleteCredentialStore, not -dropCredentialStore.
• Use -userAlias, not -u, for passwordless job execution.

Heads up: the sibling launchers vdt-export.sh, vdt-import.sh and vdt-vgpp.sh ship with the identical java -jar pattern and will throw the same JAXB / OGGV-80010 error. Patch each the same way back it up, find its Main-Class with unzip -p <jar> META-INF/MANIFEST.MF, and swap -jar for -cp "${JAR_PATH}${CLASSPATH}" <that-main-class>.

Environment: Oracle GoldenGate Veridata 23c (NextGen) CLI, JDK 17.0.12, Oracle Linux. If this saved you an afternoon, leave a comment with your version  I’m curious how many releases ship the launcher this way.