Smack 4.1.0-Alpha4 and an issue with ProviderManager.addStreamFeatureProvider

It looks like Smack 4.1.0-Alpha4 has introduced generic types into the ProviderManager class.

Unfortunately the signature of the addStreamFeatureProvider now looks like this:

addStreamFeatureProvider(String elementName, String namespace, PacketExtensionProvider<PacketExtension> provider)

Which seems to require a parameter of type PacketExtensionProvider to be provided. Seeing as how PacketExtension is an interface, my code is now getting all kinds of compiler errors. Previously the following would work fine:

ProviderManager.addStreamFeatureProvider(ELEMENT, NAMESPACE, new StreamManagementStreamFeatureProvider());

But now it fails to compile.

It feels like the method should actually be:

addStreamFeatureProvider(String elementName, String namespace, PacketExtensionProvider<? extends PacketExtension> provider)

To allow for extension of PacketExtension and not just packet extension itself.

Or am I missing something?

1 Like

new StreamManagementStreamFeatureProvider()

but you shouldn’t really need to do that. Smack automatically registers this provider, you don’t need to do it manually.

new StreamManagementStreamFeatureProvider<PacketExtension>()

That doesn’t work as StreamManagementStreamFeatureProvider doesn’t take any type parameters

As I mentioned in the other thread, using SmackTcpSmackInitializer doesn’t want to work for me. If you have documentation which explains exactly how to use it, I would be grateful if you could point me in the right direction as I know it should be working but in my tests, it does not intiialise stream management.

But that’s only tangentially related to this problem which is that this API is available to developers to use and it doesn’t really work as it stands. Would it be possible to refactor the StreamManagementStreamFeatureProvider to take a type extension or alter the addStreamFeatureProvider method on ProviderManager to not demand a PacketExtensionProvider that only has a type parameter of ?

Thanks.

Edit: Adding some test code to help clarify the situation.

If doing the following

SmackTcpSmackInitalizer smackTcpSmackInitalizer = new SmackTcpSmackInitalizer();
smackTcpSmackInitalizer.initialize(); XMPPTCPConnection.setUseStreamManagementDefault(true);

I would expect stream management to be enabled.

However, once I log into my server and then ask the connection if stream management is enabled…

connection.isSmEnabled()

I get false returned.

If I then ask the provider manager for the stream feature provider…

ProviderManager.getStreamFeatureProvider(StreamManagement.StreamManagementFeature.ELEMENT, StreamManagement.NAMESPACE);

I get a null returned.

Is this how the SmackTCPSmackInitializer is supposed to be used or any I doing it wrong?

Edit: More info.

When debugging into ProviderManager I can see the SmackTcpSmackInitializer being used and a ProviderLoader being passed in with the correct ‘sm’ stream feature provider, but the code in ProviderManager.addLoader ignores it and never adds it to the collection of stream feature providers.

The code in ProviderManager.addLoader also has checks for null on loader.getIQProviderInfo() and loader.getExtensionProviderInfo() which appears to do nothing as those collections always return an empty LinkedList and are never null. See ProviderFileLoader.

Looks like commit b348ebfd6db4bcd3c28bb0cd8bc713808d898876 to the Smack repo has added the code to ProviderManager that will register StreamFeatureProviders.

Cheers.

Right, I also found a second typo that prevented the StreamManagementFeatureProvider from being registered. It should now work as promised without any manual action(s) necessary.