Smack OSGi compatibilty

This post refers to the discussion initiated by me: http://community.igniterealtime.org/message/233292

Now, I have a solution regarding the OSGi compatibilty of the current Smack release 3.3.1 which seems to work perfectly, but it has to be tested. It is absolutely inline with the standalone solution. If we use Import-Package or Require-Bundle, smack.jar must be equipped with the smack.providers file. This creates a dependency between smack.jar and smackx.jar. If you want to keep both bundles isolated, we must declare **smackx.jar **as a Fragment-Bundle. This is the way how we can extend the classpath of smack.jar dynamically at runtime. The ProviderManager finds smack.providers and loads the classes from the Fragment-Bundle.

Please find attached the modified bundle versions:

  • smack_3.3.1.v20131029.jar now declares the correct Bundle-Version 3.3.1
  • smackx_3.3.1.v20131029.jar is now a Fragment-Bundle. I have corrected the Export-Package declaration. It does not make sense to export the packages from smack_3.3.1.v20131029.jar again.

Is this an adequate solution for the new release 3.3.2?

– Update 2013-10-29 –

Eclipse is not able to detect the package export of the fragment correctly… You have to add Eclipse-ExtensibleAPI: true to the the manifest-file of the host bundle (smack_3.3.1.v20131029.jar) and Eclipse-PatchFragment: true to the fragment bundle (smackx_3.3.1.v20131029.jar). I have attached the corrected bundles.
smack-3.3.1.v20131029.jar (347319 Bytes)
smackx-3.3.1.v20131029.jar (721658 Bytes)

Jens,

since you seem to use OSGi and Smack, could you comment on how Smack 4.0 does with regard to OSGi compatibility? Smack 4 should have the same OSGi configuration as Smack 3.

You have made a big step forward regarding OSGi compatibility. The fragment approach seems to work properly, but I had not enough time for extensive testings. It took me some time to get the 4.0.0-RC1 working under OSGi, because the manifest file is invalid. Please refer to http://community.igniterealtime.org/thread/52419?tstart=0.

I also got a “NoResponseException” using Smack 4.0.0-RC1 and OpenFire 3.8.2. After disabling the “SecurityMode”, I got 4.0.0-RC1 working and was able to made a first run of my use case. Good news: It worked… At the moment 4.0.0-RC1 is not running under OSGi because of the incorrect manifest file. Please fix it and examine the “SecurityMode” problem.

I am using a basic configuration including “smack-core-4.0.0.rc1”, “smack-extensions-4.0.0.rc1”, “smack-resolver-javax-4.0.0.rc1” and “smack-tcp-4.0.0-rc”.

Would you mind testing the latest Smack version from https://github.com/Flowdalic/Smack/tree/tlsexception

It includes 858492 which should fix the Bundle-Version, but also includes a draft commit, which should (theoretically) replace the NoResponseException with some kind of GernalSecurityException or SSLHandshakeException.

The SecurityMode problem is basically that if you SSLContext rejects the TLS connection, Smack would not throw a meaningful exception but a NoResponseException. The tlsexception branch may fixes this. I say ‘may’ because I hadn’t time to test it.

Note that the Bundle-Version is with this branch ‘4.0.0.rc2-SNAPSHOT’. If I read the OSGi spec right, the dash is allowed in the qualifier.

Oh, I am sorry. You are right of course, the dash can be used at the fourth position.