Removing the assert statement relegates the validation to XWSS, which results in a nasty NPE if a callback handler is required but not assigned. Unfortunately, there doesn't seem to be a better solution.

Another option is create a boolean property to set if the interceptor will be used in the client with token profile. But I think it isn't a good solution. Maybe we have to close the issue and keep as it is.

What I meant is that we can't do better than removing the assertion. Ideally, XWSS would validate its configuration and would throw sensible exceptions in case of error, which doesn't seem to be the case. There doesn't seem to be a simple way to interrogate XWSS about the loaded configuration either.

I think it's a best practice to configure xwss in Spring config as much as possible. For instance, you can use the SimpleUsernamePasswordCallbackHandler as opposed to supplying the credentials inline.

Secondly, XWSS does not do a proper configuration check before initializing. So if we'd drop the callbackHandler check, most people will end up with nasty NPEs, which are harder to debug then assertion failures. Even though these failures are not 100% correct, as you pointed out.