bosh uaa not running after upgrade failing with ClassCastException
search cancel

bosh uaa not running after upgrade failing with ClassCastException

book

Article ID: 293861

calendar_today

Updated On:

Products

Operations Manager

Issue/Introduction

After installing HealthWatch Tile bosh director uaa stops working showing a message related to a failure where class java.lang.Double cannot be cast to class java.lang.String
 

2023-01-10 13:42:31.853] uaa - 16 [main] .... ERROR --- DispatcherServlet: Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'clientAdminBootstrap' defined in ServletContext resource [/WEB-INF/spring/oauth-clients.xml]: Invocation of init method failed; nested exception is java.lang.ClassCastException: class java.lang.Double cannot be cast to class java.lang.String (java.lang.Double and java.lang.String are in module java.base of loader 'bootstrap')


This is a really rare case that can happen if the secret of a UAA client generated in /var/vcap/jobs/uaa/config/uaa.yml in bosh director VM, contains only numbers and the letter 'e'. This will be interpreted as a Double in scientific notation instead of a String, and will fail to be converted to String.

E.g
 

 p-healthwatch2-pas-##########-ee7###############91:
      access-token-validity: 600
      authorities: bosh.teams.p-healthwatch2-###-#########-dc###########aea491.admin,credhub.read,credhub.write
      authorized-grant-types: client_credentials
      override: true
      refresh-token-validity: 86400
      scope: ''
      secret: 71################06
      id: p-healthwatch2-###-########-ee72###########a491


The 'e' in secret value '710#################1406' is interpreted as the exponent in scientific notation and the whole thing as a Double instead of a String.

Environment

Product Version: 2.10

Resolution

R&D is working on solving the issue so the "secret" value is always interpreted as a String. This fix will be included in future version.

In the meanwhile, the easiest way would be to delete and install the Tile again so the a new secret is generated. The odds are that it will not contain again only numbers and the letter 'e' but any other combination that will prevent the error from happening again.

Note: This can potentially happen while installing any other Tile and workaround would be same, delete and install the Tile again.