Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP Bug #115

Open
Prometheus89 opened this issue Oct 2, 2017 · 3 comments
Open

HTTP Bug #115

Prometheus89 opened this issue Oct 2, 2017 · 3 comments

Comments

@Prometheus89
Copy link

Hello,

I have encountered a weird bug when using the XBeeJavaLibrary and HTTP. I am developing an application with an XBee connected to a PC that is supposed to collect data from some sensors. The data should be persisted in a remote database (Apache Jena) which I have to use HTTP for. Usually that should not be the problem since the database API offers some nice abstractions, which at the end wraps up and HTTP Post and sends it to the database.
If I want to use that abstraction, or any of Apache HTTP for that matter, the implementation does not work because of a runtime error stating the message "Stub!". After some debugging it turns out that by default the HTTP implementation from Apache located in the android sdk that is shipped with the xbee library is used, instead of the one I am providing through gradle. And in that (android) implementation the classes used in the PC-version of the HTTP library are all deprecated and just throw a runtime exception as a hint that they are deprecated.
When looking deeper into the code it turns out that at some point the types are pointing towards the android sdk. The imports in those classes just point to "org.apache...". At this point the JVM behaves silly: since there are technically two packages with the same name in the classpath it just resovles the first one, in my case the android one, since it is located in a "com" package rather then a "org" package. Does this mean that you can not use the xbee library with anything that it might collide with in the android sdk?

I really like the XBee devices and the library, since there are easy to use, which makes it handy when it comes to teaching (I am working at an embedded systems departement at a university). I have used the last version of the library before and I would like to continue using it, but not having the ability to use HTTP kind of defeats the purpose, especially in an Internet of Things context.

Do you have any suggestions, help insights?

Regards,
Prometheus

@rubenmoral
Copy link
Member

Hi @Prometheus89,

As you say, it seems that the JVM is using the Apache APIs included in the android-sdk-5.1.1.jar library instead of the standard ones. We provide the Android SDK for those users who want to extend or modify the XBee Java Library, since it is necessary in order to compile the project.

If you are not using Android, you don't need to include that library in the classpath, you just need to have the following ones: xbee-java-library-X.Y.Z.jar, rxtx-2.2.jar (with its native file), slf4j-api-1.7.12.jar and slf4j-nop-1.7.12.jar.

Hope this helps!

Regards,
Ruben

@Prometheus89
Copy link
Author

Hey Ruben,

thanks for the quick reply.
I am using Gradle for my dependencies and it turns out that android and the logging are transitive depencies that will be used automatically, even if I do not specify them. Usually this is a neat feature and makes the build files a lot sleeker, but in my case it makes it unnecessary hard. But I found a solution, I can specifically exclude transitive dependencies and now it works like a charm.

I don't know if you can change the transitive behaviour on your side. It might be worth thinking about it, because it can take a lot of time to figure out, that you might have dependency collisions with other packages you did not specifically included. (It took me about 2 days to figure that out)

Regards,
Prometheus

@rubenmoral
Copy link
Member

Glad to hear that! Yes, we will fix that behavior for the next release.

Sorry for the inconvenience.

Regards,
Ruben

@rubenmoral rubenmoral reopened this Oct 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants