I don’‘t think the current method of declaring custom packet extensions is as easy and extensible as it should be. This forum probably contains 100 different posts from people who don’‘t realize that their smack.provider file is being overridden by the smack.provider file in smackx.jar. Although for most client apps this can be worked around by manipulating the classpath, deploying a Smack client within a web application further complicates the problem. In the latter case, you are at the mercy of the container’'s class loading and may not be able to enforce the order properly.
Instead, I propose limiting the smack.providers file in smackx.jar to only the default providers used in Smack. To support custom extensions, add a mechanism to Smack to load custom providers files. This could be done in client code and/or by modifying Smack to look in a certain location on the classpath for custom provider files.
Thoughts?
Any developers want to chime in on this? Was hoping for some feedback.
I think this feature was added to the SoC-branch in August.
btw, you can programatically add extensions to the pool. I used that in my project, and it works fine, with to worries about provider files etc.
Hey Jeff,
Thanks for the feedback. We were discussing this issue with Matt and decided to implement the following changes to Smack. Core provides will no longer be included in the smack.providers file. They will be added programmatically. Therefore, smack.jar will no longer include META-INF/smack.providers. Only smackx.jar will include META-INF/smack.providers with the providers defined in the smackx packet provided by Jive.
Since Smack will load all META-INF/smack.providers found in the classpath then custom extensions, that were not added programmatically, will have to be included in a new META-INF/smack.providers file contained in your new .jar file that includes your custom code.
What do you think of that solution? So custom code should be included in its own jar file that includes its own META-INF/smack.providers file.
Regards,
– Gato
Gato,
Thanks for considering these changes. I did not realize that you could add providers programmatically, so that is probably a decent work-around at the very least. However, unless I misunderstood, it seems like you would still end up with a classpath conflict between the smack.providers file found in smackx.jar and the one found in a custom jar. That is, the only way to load your custom providers file is to ensure that it has first priority in the classpath.
The way I had envisioned it would work was that there could be a custom.providers file that Smack looks for in META-INF and parses in the same manner it would smack.providers. That way it would remain backward compatible in that it would still look for META-INF/smack.providers - it would just look for META-INF/custom.providers too.
As I mentioned in my first post, the classpath conflict can be an issue if Smack is being used from a container which does not allow for low level control of class loading.
Cheers,
Jeff
Hey Jeff,
Smack will load ALL META-INT/smack.providers that were found in the classpath so there should not be any conflict. All you need to do is create a .jar file with your code and include your META-INT/smack.providers for the new providers that are in your code. Smack will then load the META-INT/smack.providers found in smackx.jar and in your .jar file.
Does it make sense?
Thanks,
– Gato
Gato,
Makes sense now
I think that will make for a very useful change. BTW, I’'m assuming that this will be part of Smack 3.0? Is there a release estimate for 3.0? We are trying to hold off on refactoring our 2.x code until 3.0 is official (rather than go off of nightly builds).
Thanks,
Jeff
Hey Jeff,
Current version of Smack already loads ALL smack.providers files found in the classpath. So you can create your own .jar file with your classes and include your smack.providers file.
Regarding Smack 3.0 that is a very good question. We would like to finish reviewing code that was contributed by a community member that will help Smack be 100% percent compliant with XMPP 1.0 and also finish reviewing pubsub support. I would say that it will happen in 1 or 2 months from now unless there is a changes in our priorities.
Regards,
– Gato