I’m using the smack library in a project based on Knopflerfish OSGi.
When I have introduced the new version of the library (4.0.4, previously I was using the 3.4.1), I had an error of type unsupported-feature, trying to execute an ad-hoc command on a client.
Debugging the code I have found that the error was due to the fact that the smack-core initializer fails, with a ClassNotFoundException, when it tries to load these classes, contained in the smack-config file:
I’ve solved this issue, adding in the manifest file of smack-core, in Import-package also: org.jivesoftware.smack.util.dns.javax and org.jivesoftware.smack.initializer.extensions (because I don’t need experimental and legacy).
Is this the expected behaviour? If you need to use an optional initializer contained in a Smack bundle that is not smack-core, you have to add the package to the manifest of smack-core or is there another way?
Debugging the code I have found that the error was due to the fact that the smack-core initializer fails, with a ClassNotFoundException,
Indeed, in a OSGi environment smack-core is not able to initialize the other smack components (which are OSGi bundles).
Unfortunately, this didn’t guarantee the initialization order of the bundles, so it is still possible to create a XMPPConnection while Smack is not fully initialized: [4.1.0-alpha1] SASL Authentication missing in OSGi
Jens and I are working on a solution. Until one is found, you have to manually initialize the Smack components before you create a XMPPConnection (e.g. by using a static block in the class that creates XMPPConnections).
I’ve solved this issue, adding in the manifest file of smack-core, in Import-package also: org.jivesoftware.smack.util.dns.javax and org.jivesoftware.smack.initializer.extensions (because I don’t need experimental and legacy).
I don’t recommend messing with the manifest, instead mimic what SmackInitializer would do. That is for every existing optional startup class do