Quantcast
Channel: Ignite Realtime: Message List
Viewing all articles
Browse latest Browse all 12162

Re: [4.1.0-alpha1] SASL Authentication missing in OSGi

$
0
0

Is this causing problems when using OSGi or just a "OMG, they use unofficial API which nobody should do" warning? If it's the latter, then to be honest, I don't see the immediate need to change it. I'd rather use the sun native API instead of duplicating the code from there into Smack for now. The mid-term goal is to write a XMPPHostnameVerifier that also takes the service name as third argument. But such code is security critical, errors can be disastrous, and I wont let anything like the ServerTrustManager disaster happen again. So until there is a bullet-proof, 100% XMPPHostnameVerifier, Smack is going to use the same code that is used by many others programs from the native sun API.

The header entry MUST be removed because its a native package and not exported by the OSGi framework. The bundle cannot be resolved. It is up to the OSGi framework deployer to declare this package as beeing "bootdelegated". This tells the classloader of the bundle to delegate a corresponding package request to the installed JRE. Only remove this entry and leave the "magic" of resolution to OSGi .

Back to the OSGi startup dependency problem. Just that I understand the situation correctly: If you would perform '(new SASLJavaXSmackInitializer).initialize()' somewhere in your code before you are using Smack, then everything would be fine, right?

Right now, I don't understand what makes smack-sasl-javax different from every other class where we use OSGi declarative services (e.g. smack-experimental). Could you elaborate that?

There is no real difference and the problem occurs also in all other bundles (smack-experimental, smack-extensions,...). I told you that I am using only a subset of Smack (smack-core, smack-extensions) and I am registering my own ExtensionProviders based on JAXB in Smack and do not care about those added by "smack-extensions" so the problem is covered, but still present.

Back to the OSGi startup dependency problem. Just that I understand the situation correctly: If you would perform '(new SASLJavaXSmackInitializer).initialize()' somewhere in your code before you are using Smack, then everything would be fine, right?

That would be possible, but OSGi is a shared environment and the XMPP lib gets shared between multiple consumers. The call SASLJavaXSmackInitializer should be done only once and not by everyone who uses Smack in a bundle.


Viewing all articles
Browse latest Browse all 12162

Trending Articles