Possibility of disabling xsuaaMtlsRestOperations bean if XsuaaServiceConfiguration is not provided

[fbunsmann]

Question Summary

• client library: spring-xsuaa version 2.11.1
• Environment: Cloud Foundry

We are currently in the process of changing our xsuaa bindings to x509 credentials for our spring applications. We are also using CAP as a framework, and we have discovered a small issue regarding the XsuaaAutoConfiguration. For the x509 case, a bean xsuaaMtlsRestOperations is configured which requires a parameter of type XsuaaServiceConfiguration. Usually, this is not a problem but with CAP there is use case to run a Cloud Foundry task for database migration on the java application which is executed with security disabled (because it does not expose any endpoints). You can check in their docs here. In this scenario, CAP does not provide any bean of type XsuaaServiceConfiguration and the application startup fails with the following exception:

org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'xsuaaMtlsRestOperations' defined in class path resource [com/sap/cloud/security/xsuaa/autoconfiguration/XsuaaAutoConfiguration.class]: 
Unsatisfied dependency expressed through method 'xsuaaMtlsRestOperations' parameter 0; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: 
No qualifying bean of type 'com.sap.cloud.security.xsuaa.XsuaaServiceConfiguration' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
    at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:800)
    ...

Would it be an option for you to only provide a bean xsuaaMtlsRestOperations if XsuaaServiceConfiguration is provided, or in other words to make xsuaaMtlsRestOperations conditional on bean XsuaaServiceConfiguration?

If you have any further questions, let me know.

Regards, Florian

[liga-oz]

Hi @fbunsmann,

With XsuaaAutoConfiguration the XsuaaServiceConfiguration bean is conditional on missing bean of this type, which means this bean should always be there and with that also one of the RestOperation beans get initialised, as long as you don't use RestOperations bean you shouldn't see any exceptions even if you do not have xsuaa configuration present.

One option I see, if you don't have the XsuaaServiceConfiguration and don't need the RestOperations is to disable the autoconfiguration like so: @EnableAutoConfiguration(exclude={XsuaaAutoConfiguration.class})

BR, Liga

[beckermarc]

With XsuaaAutoConfiguration the XsuaaServiceConfiguration bean is conditional on missing bean of this type, which means this bean should always be there

This is not correct, as XsuaaAutoConfiguration allows to disable the default XsuaaServiceConfiguration bean which XSUAA provides, by setting spring.xsuaa.disable-default-property-source (see https://github.com/SAP/cloud-security-xsuaa-integration/blob/2.11.1/spring-xsuaa/src/main/java/com/sap/cloud/security/xsuaa/autoconfiguration/XsuaaAutoConfiguration.java#L48). CAP leverages that.

Please consider defining the MTLS RestOperations conditional on XsuaaServiceConfiguration, as also @fbunsmann suggested, as it is in fact conditional on that bean :)

And not using RestOperations is unfortunately not enough to not see any exceptions, as this bean is not required in the use-case described by @fbunsmann, but nevertheless Spring still tries to create it and raises an exception due to the missing XsuaaServiceConfiguration.

[liga-oz]

Ok, I see, thanks for additional information.

And not using RestOperations is unfortunately not enough to not see any exceptions

In case spring.xsuaa.disable-default-property-source is not disabled it is enough.

Any objection disabling XsuaaAutoConfiguration as a workaround? Doesn't seem that you need it.

[fbunsmann]

Any objection disabling XsuaaAutoConfiguration as a workaround? Doesn't seem that you need it.

Yes as a workaround we are doing just that right now. It's just that more people will probably run into the same issue which is also not so easy to understand in the first place. Also I think from a logical perspective making xsuaaMtlsRestOperations conditional on bean XsuaaServiceConfiguration seems to be the right thing. Is there any specific reason why you would like to keep it as it is? If there is, the other alternative is that CAP updates their documentation and mentions the needed disabling of autoconfiguration there. I assume almost every consumer of CAP Java also uses spring-xsuaa.

[liga-oz]

Any objection disabling XsuaaAutoConfiguration as a workaround? Doesn't seem that you need it.

Yes as a workaround we are doing just that right now. It's just that more people will probably run into the same issue which is also not so easy to understand in the first place. Also I think from a logical perspective making xsuaaMtlsRestOperations conditional on bean XsuaaServiceConfiguration seems to be the right thing. Is there any specific reason why you would like to keep it as it is? If there is, the other alternative is that CAP updates their documentation and mentions the needed disabling of autoconfiguration there. I assume almost every consumer of CAP Java also uses spring-xsuaa.

The change will come most likely in the 2.11.5 release, thanks for the insights 👍🏻

[fbunsmann]

Thanks a lot! 👍