Hi all.
I know there are many users seeing this warning. OK, every developer could just add the smackx.jar to the classpath and the warnings would disappear, right?
But if I understand the documentation right, the smack.jar contains all code for plain XMPP standardized usage and the smackx.jar are OPTIONAL extensions. If this is the case, why are the classes from the smackx.jar beeing loaded by default? Shouldn’t it be the other way around?: The default would be not to load those extension classes until they are called or beeing configured.
From: http://www.igniterealtime.org/builds/smack/docs/latest/documentation/gettingstar ted.html
"smack.jar – provides core XMPP functionality and is the only required library. All XMPP features that are part of the XMPP RFCs are included."
Or did I missunderstand this. A citization from: http://community.igniterealtime.org/message/145498#145498
“It is very simple: you need to specify in the CLASSPATH the smackx package. Although you do not use it explicitely, there’'re classes and packages in Smack that do use smackx package.”
So if there are dependecies from smack.jar to smackx.jar that are there for every usage:
As far as I can see this is a common issue new users of smack are confronted with. I think all actors may save some time, if this would be changed or at least documented. This is a predestinated case for an FAQ, isnt it?
This should be just some constructive critics. I hope I did not oversee something. Apart from that, I think smack is great work. Thanks to all contributors.
Thanks in advance.
1 Like
You are correct in that this should not really be set up this way. You should be able to use Smack on it’s own without the dependencies to classes in smackx. That being said, the errors you are seeing can be ignored, it is simply reporting that those classes cannot be loaded. It does not keep smack from working, the only problem is that the configuration should not default to trying to load classes from smackx.
You may see a similar problem from classes loaded in the smack.providers file as well. If you want to get rid of the noise, you can edit and replace the smack-config.xml and smack.providers files in META-INF in the smack.jar file with ones that do not reference classes that are not in the smack jar (anything with smackx in the package name).
This will hopefully change in the future, but it will have to wait for a major release since it would break a lot (if not 99%) of existing code.
Thank you for answering.
Do you really think, that this change would break existing code? Are there any API changes needed or only internal implementation details?
I think this should be reported to the issue tracker, maybe as an improvement. Looks like there is no issue filed on this topic, yet.
It would be nice if the logins from the forum would work in the issue tracker, too.
Logged as SMACK-381.
Well, we can’t just pull the content of the files out, that would definitely break things. It may be possible to alter the code that reads the file to read from multiple locations, and include a default secondary location in the smackx jar, if it is found. The multiple locations is needed for the smack.providers file anyway to allow easy customization, like working in Android, for instance.
All right. I just wanted to do my part as a user of smack to drive this issue a bit forward. Thanks again.
1 Like