IBM Directory Integrator error "unknown format type at"

So here's a strange one that I didn't find anywhere in my numerous searches, so I figured I would post it here. When running a TDI AssemblyLine, I got the following exception / error:

12:14:43,274 ERROR - [My-JDBC-Connector] CTGDIS810E handleException - cannot handle exception , addonly

java.lang.IllegalArgumentException: unknown format type at

        at com.ibm.icu.text.MessageFormat.makeFormat(MessageFormat.java:2086)

        at com.ibm.icu.text.MessageFormat.applyPattern(MessageFormat.java:589)

        at com.ibm.icu.text.MessageFormat.<init>(MessageFormat.java:437)

        at com.ibm.icu.text.MessageFormat.format(MessageFormat.java:1137)

        at com.ibm.di.util.ParameterSubstitution.substitute(ParameterSubstitution.java:229)

        at com.ibm.di.util.ParameterSubstitution.substitute(ParameterSubstitution.java:173)

        at com.ibm.di.util.ParameterSubstitution.substitute(ParameterSubstitution.java:245)

        at com.ibm.di.connector.JDBCConnector.putEntry(JDBCConnector.java:1202)

        at com.ibm.di.server.AssemblyLineComponent.executeOperation(AssemblyLineComponent.java:3351)

        at com.ibm.di.server.AssemblyLineComponent.add1(AssemblyLineComponent.java:2012)

        at com.ibm.di.server.AssemblyLineComponent.add(AssemblyLineComponent.java:1965)

        at com.ibm.di.server.AssemblyLine.msExecuteNextConnector(AssemblyLine.java:3780)

        at com.ibm.di.server.AssemblyLine.executeMainStep(AssemblyLine.java:3391)

        at com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:2989)

        at com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:2972)

        at com.ibm.di.server.AssemblyLine.executeAL(AssemblyLine.java:2939)

        at com.ibm.di.server.AssemblyLine.run(AssemblyLine.java:1317)

12:14:43,276 ERROR - CTGDIS266E Error in NextConnectorOperation. Exception occurred: java.lang.IllegalArgumentException: unknown format type at

java.lang.IllegalArgumentException: unknown format type at

        at com.ibm.icu.text.MessageFormat.makeFormat(MessageFormat.java:2086)

        at com.ibm.icu.text.MessageFormat.applyPattern(MessageFormat.java:589)

        at com.ibm.icu.text.MessageFormat.<init>(MessageFormat.java:437)

        at com.ibm.icu.text.MessageFormat.format(MessageFormat.java:1137)

        at com.ibm.di.util.ParameterSubstitution.substitute(ParameterSubstitution.java:229)

        at com.ibm.di.util.ParameterSubstitution.substitute(ParameterSubstitution.java:173)

        at com.ibm.di.util.ParameterSubstitution.substitute(ParameterSubstitution.java:245)

        at com.ibm.di.connector.JDBCConnector.putEntry(JDBCConnector.java:1202)

        at com.ibm.di.server.AssemblyLineComponent.executeOperation(AssemblyLineComponent.java:3351)

        at com.ibm.di.server.AssemblyLineComponent.add1(AssemblyLineComponent.java:2012)

        at com.ibm.di.server.AssemblyLineComponent.add(AssemblyLineComponent.java:1965)

        at com.ibm.di.server.AssemblyLine.msExecuteNextConnector(AssemblyLine.java:3780)

        at com.ibm.di.server.AssemblyLine.executeMainStep(AssemblyLine.java:3391)

        at com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:2989)

        at com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:2972)

        at com.ibm.di.server.AssemblyLine.executeAL(AssemblyLine.java:2939)

        at com.ibm.di.server.AssemblyLine.run(AssemblyLine.java:1317)

The problem was that I had a scriptable field in a connector that was set as "Text w/substitution", but needed to be set to "Advanced (JavaScript)". Sometimes (with only a tiny bit of JavaScript, for example), you can get away with this. But in my case, I had a LOT of JavaScript and this error was the result.

To figure that out, I put lots of debugging code in the JavaScript itself and in the Component Hooks around when this field should have been evaluated.

Tivoli Directory Integrator Entry.toJSON() function produces bad JSON for single-element arrays

 TDI lets you create a JSON string from an Entry type object using that class's toJSON() method. It works like a champ UNLESS you happen to have a property that is an array with a single element, like this:

entry = system.newEntry()

entry.foobar = [ "0" ];

task.logmsg(entry.toJSON());

That will produce the following string:

{ "foo":"0" }

Whereas it should produce:

{ "foo" : [ "0" ] }

If you have two or more elements in the array, it works perfectly. 

To fix the issue, I used the following code:

goodString = entry.toJSON().replace('"foobar":"0"','"foobar":["0"]');

And now everything is good. Whew!

Setting DISPLAY in .bashrc on AIX doesn't work in at least one strange situation

 Here's what I tried in  my .bashrc:

DISPLAY=$(who am i | perl -pe 's/.*\((.*)\)/$1:0.0/')
export DISPLAY

Here's the result:

$ xterm

Warning: This program is an suid-root program or is being run by the root user.

The full text of the error or warning message cannot be safely formatted

in this environment. You may get a more descriptive message by running the

program as a non-root user or by removing the suid bit on the executable.

xterm Xt error: Can't open display: %s

xterm:  DISPLAY is not set

$ echo $DISPLAY

10.110.2.214:0.0
$ export DISPLAY=10.110.2.214:0.0

$ xterm

(xterm displays as expected)

This drove me crazy for longer than it should have. I even ran:

echo $DISPLAY | od -c

and that showed no extra characters at all. I was at my wit's end until I simply tried a different set of commands to set DISPLAY. The one that works is:

REMOTE_HOST_IP=$(who am i | awk '{print $NF}' | tr -d ')''(' )

DISPLAY=$REMOTE_HOST_IP:0.0

export DISPLAY

This is on AIX 7.3, with what I'm certain are strange and old versions of perl and bash (they behave oddly in other situations, too), but wanted to share my silly solution.

Tivoli Directory Integrator Certificate Chain Exception

 Saw this error today in an HTTP Client Connector in TDI 7.1.1:

 java.security.cert.CertPathValidatorException: Certificate chaining error

I had the remote host's entire certificate chain imported into serverapi/testadmin.jks . I also made certain that my solution.properties file was pointing to the correct JKS file, restarted the TDI CE multiple times, and it simply kept failing. I thought I was going crazy, so I:

• stopped TDI CE
• moved testadmin.jks
• zeroed out testadmin.jks
• started TDI CE
• Went to the connector and clicked "Get Certificate" and it complained, whereas before it said "Certificate is already trusted", so I knew I was dealing with the correct JKS file.
• FINALLY, out of desperation, I deleted the server certificate, but left the other two certs in the chain (the signer and the signer of THAT certificate), and THEN IT WORKED.

So I'm not certain what the moral of the story is, but that's how I solved this problem, which is slightly different than I've seen anywhere else and I wanted to record it to hopefully help anyone who runs into this in the future.