-
Notifications
You must be signed in to change notification settings - Fork 237
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
[ModuleClient] IllegalArgumentException on ModuleClient.createFromEnvironment #281
Comments
This is a bug on our side, and I'll get a fix in for this soon. Thanks for opening the issue. |
The fix for this issue has been checked into this branch if you want to try building from source to try it out. We will be merging this into master and releasing within 2 weeks, but I would appreciate any feedback you have on this fix before then. |
Sorry. But fix doesn't work. New error message:
Did you test the fix? |
Sorry about that, there was a bit that I missed during testing. I pushed another commit that should work for you. |
No problem. This time with NPE
Sincerely your test bot |
I fixed a few more issues with this functionality, so now would be a good time to pull the latest and try again. I really appreciate the testing help! |
Still crashing
|
We're just about done fixing this flow. I pushed one more commit that should do it for you. I added a little extra logging via System.out. When you run this again, can report back to me what your logs look like in their entirety (with connection strings censored)? I added that logging temporarily to understand the form of the data that the hsm is returning. There was an odd requirements mix up between this SDK and the Edge team that this logging should clear up. |
OK. Next try. Again with NPE. BTW. I had to rewrite my Java sample app to get logging enabled in the SDK. Before, with a Spring Boot app, I could not manage to get logging information from the SDK. This is a known bug, that I've already reported 1.5 years ago, and the reason comes from the direct usage of Log4j in CustomLogger.
|
I pushed another commit that should fix that issue for you. Again, I added some extra logging just in case something goes wrong again. Just for some context, the flow you are using here is communicating with an HSM to create a sas token for authentication and to get the trust bundle. Based on your logs, it looks like you retrieved the sas token just fine, and with this fix, you will get the trust bundle, too. After that, the rest of this flow has been tested and it works. It was just the HSM steps that we don't have a nice automated test on yet. Thanks again! |
And now with StackOverflow from gson library. See attached log file |
Looks like there was an issue with our gson parser class missing a default constructor. I went ahead and committed the fix to a different branch for you to try out. |
Sorry. But the new branch doesn't compile:
|
Whoops, you are absolutely correct. I forgot to update a few tests. Sorry about that. I just pushed a commit that should allow you to compile now. |
Heureka! It works now without any exception, even when sending messages. Unfortunately the sent messages are not arriving at the IoT Hub. I've already checked the routes. Anyway. I'll have to investigate further. |
Awesome! I'll keep digging with you on the routes issue. |
This issue seems to happen again with the current release: Caused by: java.lang.IllegalArgumentException: Expected URL that uses protocol HTTPS but received one that uses protocol 'http'.
Our current environment configuration is: Any ideas on how to fix this? |
This issue seems to occur with the newest version again. Could we reopen the issue? |
OS and version used: Windows 10 with Docker CE and Linux containers
Java runtime used: OpenJDK 8
SDK version used: 1.13.1
Description of the issue:
On calling ModuleClient.createFromEnvironment() with MQTT as protocol at startup, the method fails with an IllegalArgumentException. com.microsoft.azure.sdk.iot.device.hsm.HttpsHsmClient.sign() method is using HttpsClient and tries to open a connection to "IOTEDGE_WORKLOADURI=http://10.0.75.1:15581/", that will fail because the URL contains 'http' but not 'https'
Code sample exhibiting the issue:
Console log of the issue:
Need Support?
The text was updated successfully, but these errors were encountered: