Version file not updated after OpenAM is patched - Part II

So, according to Peter, there is a bug (See Bugster OPENAM-3280) which will impact the command line ssoadm.

I was trying out ssoadm tool yesterday and observed that the bug does not impact the setup program.

Before I patch OpenAM (which is version 10.0.0), the setup tool is able to detect the version of OpenAM correctly.

After OpenAM is patched (which is version 10.0.2), the setup tool is also able to detect the version of OpenAM correctly.

Now, once the setup is done and you start using the ssoadm command line utility, the bug will come. The command is retrieving value directly from the .version on the file-system, instead of querying directly from OpenAM Configuration Store.

By retrieving value directly from OpenAM Configuration Store, it should behave like what the OpenAM Admin Console will display.

Now, there are really some hardcode people around who insisted to use ssoadm command line utility.
(Ok, I'm just lazy. If given a choice, I'll go for UI. Using command lines doesn't make me any smarter. Ha!) Joke aside, on a more serious note, I think we are making a living trying to provide business solutions to our customers. We do not really need to insist on a certain way of doing things. If there are workarounds, go for it. Case closed, go home early and be with the family.

Back to ssoadm command line utility, before OPENAM-3280 is resolved, there is in fact a more tedious way of getting the correct version of OpenAM.

Use the export-svc-cfg sub-command. (See export-svc-cfg)

This will generate a XML file contains OpenAM Service Configuration.

Within the XML, it'll contain the current version of the OpenAM Server.

By the way, there's another bug with ssoadm. This time, it's not the command line utility issue. It's an issue with the Web UI utility (ssoadm.jsp). See Bugster OPENAM-2979 - ssoadm.jsp does not offer export-svc-cfg subcommand.



.