Configuration store servers are not listed in Directory Configuration

I was working on an Open Identity Stack (OpenAM, OpenDJ, OpenIDM) project and OpenAM 12.0.1 was installed.


When verifying my configuration, I hit into OPENAM-6499 - Configuration store servers are not listed in Directory Configuration.

So, this was caused by a recently introduced new feature - Object Deserialisation Class Whitelist. The workaround was mentioned in the bugster.

Workaround is to add the following to the openam.deserialisation.classes.whitelist

Configuration -> Servers and Sites -> Default Server Settings -> Security -> Object Deserialisation Class Whitelist

com.sun.identity.common.configuration.ServerConfigXML
com.sun.identity.common.configuration.ServerConfigXML$DirUserObject
com.sun.identity.common.configuration.ServerConfigXML$ServerGroup
com.sun.identity.common.configuration.ServerConfigXML$ServerObject

Now, customer wanted scripted installation and configuration, so I was using SSO Administration Tool as much as I could. So, I went ahead to add the 4 classes into the whitelist ... 1 at a time.

But as soon as I keyed in the 1st class and tried to navigate around OpenAM Console, I hit into Invalid URL error.

I fired up OpenDJ and realised the default list of classes that shipped with OpenAM 12.0.1 was gone. The ssoadm command override the old values! (Need to be careful next time)


Luckily I always have backups! So, the 4 classes had to be appended to the existing list of classes like the following.

But .... it became worse ... the whitelist is now empty!

 So I realized $ sign had to be "escaped" ... aka prefixed with a backward slash.

After this, the configuration store servers finally shown up!

OpenAM Performance ... with APM solution

In all my deployment of OpenAM in Production, I will always tune the JVM as well as OpenAM tunable parameters before I hand-over the SSO infrastructure to customers.

From tuning perspective, I only have 1 product in mind ... i.e. this particular JVM is supposed to run OpenAM optimally. I will not cater for any other component(s) that might be deployed on the same JVM. Honestly, if I am not told beforehand, how do I know what to cater for and which parameters to tune?


These days, APM solutions are picking up. APM vendors preach that their solutions, when deployed on the same JVM where the production codes are running, have little footprint. And thus, it is alright to run APM alongside production codes.

Really? I just had a customer who reported a JVM heap of over 80% 5-6 times per month.

Their systems/middleware team deployed the APM diagnostic tool when the SSO system went LIVE as part of their go-LIVE procedure ... without thinking of any impact/side-effect.

After removing the diagnostic tool, there is no more report of heap size issue for almost a month.

Lesson learnt I hope.

.