@wojtek You are correct. That documentation is now irrelevant as:

• factory property was replaced by sasl-provider bean (TigaseSaslProvider class) which allows you to enable multiple beans providing SASL by implementing SaslServerFactory or you can override TigaseSaslServerFactory class and its bean.
• callbackhandler and callbackhandler-${MECHANISM} properties were replaced by callback-handler-factory bean (CallbackHandlerFactory) and custom handlers may be provided by overriding that bean
• mechanism-selector property was replaced with mechanism-selector bean (DefaultMechanismSelector class which has config fields for allowed-mechanisms and non-plain-password-allowed-mechanisms)

Why it was done in that way? All of the properties allowed users of Tigase XMPP Server to reconfigure it but were related to replacing "classes" which since 8.0.0 is now done by replacing beans. Moreover, the usage of each setting forced implementation of custom class (ie. handler), so it was "ok" to "force" user to add another class like SASL provider just to add flexibility (Tigase user having custom callback handler already needs to know Tigase internals, so forcing him to add one simple class is not big request).

I'm not sure how this change should be reflected in our documentation.

Why it was done in that way? All of the properties allowed users of Tigase XMPP Server to reconfigure it but were related to replacing "classes" which since 8.0.0 is now done by replacing beans. Moreover, the usage of each setting forced implementation of custom class (ie. handler), so it was "ok" to "force" user to add another class like SASL provider just to add flexibility (Tigase user having custom callback handler already needs to know Tigase internals, so forcing him to add one simple class is not big request).

This is OK and I was expecting as such.

I'm not sure how this change should be reflected in our documentation.

@andrzej.wojcik Well, consider someone wants to implement custom SASL authentication, so (as in previous version) documentation should answer the question "How do I implement (and configure) my custom implementation of SASL mechanism?". I guess this will mostly boil to configuration part as the classes are roughly the same/similar.

I've reviewed documentation and updated it to have almost the same information as the old one but will work with new version.

Thank you.

Could you take a look at this comment https://projects.tigase.net/issue/xpertai-4#focus=streamItem-4-26562.0-0 and raised concern:

I have created a new class extending CallbackHandlerFactory as follows (It would be nice if in next developments you could set the getHandlerClassname method to public to just override this) Is this the only way to have this working? I tried to set settings configuration to load the handler using the tigase factory but the setting map was always null

It does seem like a remnant from previous map-based properties passed to plugins and it could/should be removed? IMHO making tigase.auth.CallbackHandlerFactory#getHandlerClassname public is not a bad idea - what do you think @andrzej.wojcik ?

We can make it public and should remove those map based config reminiscence

Make it protected and deprecated methods.