I'm currently creating a chat using elixir. but anytime i try running the app, the websocket gives an error on sever console
The client's requested channel transport version "2.0.0" does not match server's version requirements of "~> 1.0"
And browser console:
WebSocket connection to 'ws://localhost:4000/socket/websocket token=eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJVc2VyOjMiLCJleHAiOjE1MDQ0OTE1NTQsImlhdCI6MTUwMTg5OTU1NCwiaXNzIjoiU2xpbmciLCJqdGkiOiIyNWY5NDZkNy1jNDg5LTRiYWMtYjJkNS0zZDA4OTdkNDU1ZWMiLCJuYmYiOjE1MDE4OTk1NTMsInBlbSI6e30sInN1YiI6IlVzZXI6MyIsInR5cCI6ImFjY2VzcyJ9.nh-DaQfY8OuI0EBE7lILFx6hjm6J_ZrynXHeOLr1-wM-fXnDakqrZUSN1XFQnr0x0KM9WFOkLEQnip5DcsKxXw&vsn=2.0.0' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
your phoenix javascript library (dependency) is updated without notice. You should fix version so it is limited to less than 1.3.0 in package.json (if you are using npm) or bower.json if you are using bower to use old implementation, or use narrowtux solution if you downloaded js file manually. Or upgrade phoenix version.
With Phoenix 1.3, a new version of the transport protocol was released. It seems that you've somehow included the new version of the javascript client in your project, but are still running on Phoenix 1.2.
As a workaround, you can copy and reference the old client script here: https://github.com/phoenixframework/phoenix/blob/v1.2/web/static/js/phoenix.js
Related
I'm trying to deploy using firebase 3.0.0 latest CLI version.
Unfortunately I get this errors:
Error: Unable to authorize access to project XXXX
Note: This version of the Firebase CLI is only compatible with projects upgraded
to the new Firebase Console. To access firebase.com apps, you will need to
use a previous version: npm install -g firebase-tools#^2.1
Any ideas?
As a matter of fact I was trying to deploy to a custom domain that was not yet verified.
My bad :(
Sorry guys.
I believe you need to upgrade your project to the new Firebase at firebase.google.com. If you haven't you should check out the announcements at Google I/O 2016.
We have a MobileFirst application that worked with Worklight 6.2 server - production also. We are using a http adapter: <connectionPolicy xsi:type="http:HTTPConnectionPolicyType">
Currently we are changing the production server to 7.0.0. On Development Server we could test our application and all the functionalities were OK. We'we created the .war with the production server on build configuration and uploaded together with the android .wlapp . Now we receive 404 when the application tries to call any adapter function on production server. invokeProcedure onFailure returns UNEXPECTED_ERROR. This is with:
Server version: 7.0.0.00.20150312-0731
Project WAR version: 7.0.0.00.20150402-2001
Adapter name: XXXXX. Version: 7.0.0.00.20150402-2001
Application: XXXXX-android-0.9.7, Version: 7.0.0.00.20150402-2001
We have no security enabled in the application.
Is there something that must be enabled on Server in order to allow old type adapters call?
When we've tested with upgraded MobileFirst Development Studio 7.0.0.00.20150430 as development platform - same server version, and we got same 404 (Context not found), but there tries to connect with authorization/v1/clients/instance instead of /apps/services/api/XXXXX/android/query
Should a Server upgrade solve this problem? We've noticed that there are updates available.
The Server is on a https connection, but was same on WL 6.2.
By the description in the comments and the supplied messages.log, it is clear that you are attempting to use Application Authenticity Protection.
This feature worked in a certain way in v6.2 and it works in a different way in v6.3 and above.
From the comments it appears you are only adding the publickSigningKey - this is no longer enough.
See the updated Application Authenticity Protection tutorial for steps to follow: https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-7-0/authentication-security/application-authenticity-protection/
General steps to follow:
Setup authenticationConfig.xml with the security test
Add the security test to the environment node in application-descriptor.xml
Add the publicSigningKey to the <publicSigningKey> element
Add the application package name <packageName> element
I believe you are missing step 4.
Note that you also able to now enable the Extended Authenticity mode; follow the instructions in the tutorial.
Note about step 3: obviously the same keystore used to generate the publicSigningKey must be used when you export the signed .apk file... otherwise there will be a mismatch and the authenticity challenge will fail.
In your authenticationConfig.xml, make sure you have the securityTest available (= not commented out like in the file you've supplied in the comments below.
In your application-descriptor.xml, you are missing the securityTest attribute in the Android environment element: <android version="0.9.9"> change to <android version="0.9.9" securityTest="customTests">
I have a REST API that was working with Jersey 2.6 and Swagger 1.3.7. I read that Jersey 2.9 fixes a warning that I was getting so I upgraded to the latest Jersey 2.16 but then Swagger stopped working. I went back and upgraded one version at a time until I saw that Swagger was working with 2.15 so I settled on that. Now, the PUT API fails with Swagger with the following error:
The server refused this request because the request entity is in a format not supported by the requested resource for the requested method
The API works using FireFox RESTClient and specifying "application/json".
I do have "jersey-media-json-jackson" as a dependency and call "Client client = ClientBuilder.newClient().register(JacksonFeature.class);" in the program.
I tried upgrading Swagger but that did not help.
Has Swagger been verified to work with Jersey 2.15/2.16?
I've recently managed to get swagger-core to work with Jersey 2.16 with a similar issue. Keep in mind they are using the latest version (1.5.X) and not 1.3.X but the same solution will apply.
The problem is most likely with version resolution, specifically, the one of jackson-databind. For some reason, even jersey-media-json-jackson 2.16 depends on an older version of jackson-databind, even though it works fine with the latest version. Without having more details, it would be difficult to suggest a full solution, but you can follow the dependency tree and see the conflicts there.
If you do require further assistance, I'd suggest either using our mailing list, or even better, the IRC channel where we could interact online and resolve it.
Mule id plugin Url is not working. Can any one help to get an alternate url for the same plugin.
http://dist.muleforge.org/mule-ide/updates-2.1.x/
This url is also mentioned in the below tutorial.
http://www.mulesoft.org/documentation-3.2/display/32X/Installing+Mule+ESB+3+and+the+Mule+IDE
Below is the error which i am receiving after accessing this url in browser.
Network Error (tcp_error)
A communication error occurred: "Connection refused"
The Web Server may be down, too busy, or experiencing other problems preventing it from responding to requests. You may wish to try again at a later time.
For assistance, contact your network support team.
Mule version 2X uses the url :- http://dist.muleforge.org/mule-ide/updates-2.1.x/ and for Mule version 3X the url :- http://www.mulesoft.org/documentation-3.2/display/32X/Installing+Mule+ESB+3+and+the+Mule+IDE is being used.
You need to check the version of Mule you are using and need to use the url that matches your Mule version.
If you are using Mule Enterprise edition you can take support from the MuleSoft Support, else if you are not using Enterprise you can post the issue in their forum
I seriously doubt there is still support for the Mule IDE, it was deprecated in favour of Mule Studio (that then became Anypoint Studio).
Do you really need to do a new development on Mule 2.x? If not, please consider using the much better Anypoint studio. If you need to stick to the 2.x version, you could just use a vanilla version of eclipse that will take care of the the autocompletion and then export to the apps directory of a running mule container for a hot deployment.
Im in the process of evaluating the new interface of Apache Archiva. The user interface is really good and I was able to configure most of the settings.
However, when I try to deploy the artifact through eclipse Im getting the below error.
Error code 405, HTTP method PUT is not supported by this URL
I donot get this when I use the Apache Archiva 1.3.6.
Any idea?
This can happen if your repository URL is incorrect. See GitHub issue 4.
I have setup the new Archiva version 2.0.0. Apparently this issue has been fixed with the latest version.