With a newly scaffolded app generated from "yo jhipster" and started with "mvn spring-boot:run" and "grunt server" I am able to load the app and do operations like login, view metrics, see sessions, settings, logs, and audits. However, whenever I view the "User Tracker" page I don't see anything?
I believe this section is supposed to demonstrate Atmosphere websocket / AngularJS integration? Looking at the browser console logs, I see the following:
Websocket failed. Downgrading to Comet and resending atmosphere.js:2866
GET http://0.0.0.0:9000/websocket/activity?X-Atmosphere-tracking-id=0&X-Atmosph…true&X-Cache-Date=0application%2Fjson&X-atmo-protocol=true&_=1393276976964 404 (Not Found)
It appears that a websocket connection is attempted but eventually times out and the fallback long polling doesn't work? I'm using the latest Chrome (also tried on latest versions of Firefox and Safari as well).
Am I missing something simple?
-- Update 1 --
Deploying it as a WAR to Tomcat 7.0.50 shows data back from Atmosphere in the User Tracker page but it continuously loops trying to get a WebSocket connection (HTTP status code 101: switching protocols) so the user data appears and disappears periodically. I saw an error in Chrome like this:
No suspended connection available. Make sure atmosphere.subscribe has been called and request.onOpen invoked before invoking this method
The Tomcat logs show the following:
[WARN] org.atmosphere.cpr.DefaultAnnotationProcessor - Unable to detect annotations. Application may fail to deploy.
-- Update 2 --
Deploying it as a WAR to Jetty 8.1.14.v20131031 (Jetty 9.1.1.v20140108 throws errors) and testing it with Chrome 32.0.1700.107 appears to work for the fallback transport of long-polling. The initial connection to WebSockets, however, fails because Atmosphere for some reason thinks the servlet container is Tomcat? In the server logs, it throws the following issue:
java.lang.ClassCastException: org.eclipse.jetty.server.Request cannot be cast to org.apache.catalina.connector.RequestFacade
at org.atmosphere.container.TomcatWebSocketUtil.doService(TomcatWebSocketUtil.java:141)
at org.atmosphere.container.Tomcat7Servlet30SupportWithWebSocket.service(Tomcat7Servlet30SupportWithWebSocket.java:62)
Thanks again for all your help -- definitely making progress :)
-- Update 3 --
To summarize everything:
Currently "mvn spring-boot:run" and "grunt server" don't work together for Websockets or long-polling
If you deploy the JHipster WAR (mvn package) to Jetty 8.1.14.v20131031 then it works but you need to remove the following dependency from your JHipster pom.xml or else Atmosphere will not provide WebSocket support:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</dependency>
Argh. False alarm -- I had it running using streaming, not websockets, so WebSockets still has the error from update2
No you're not missing anything :-)
If you use the Java server directly it should work: you need to connect to the application with another browser (or another tab) and you will see working.
However, with "grunt server", there is a bug: the Grunt proxy just does not support Websocket, so it doesn't work... There is one strange thing, thus, it's that the fallback transport does not work.
I'm filling this as a bug.
-- update 1 --
Concerning your update, it looks there's another Atmosphere bug:
http://atmosphere-framework.2306103.n4.nabble.com/Log-warning-that-Atmosphere-is-unable-to-detect-annotations-td4658159.html
It seems that Atmopshere can't find its annotation inside a WAR, can you try the same thing in development mode ("mvn spring-boot:run")? That would means it's an issue with WARs in Tomcat
Related
I just started learning about React.js and I have been noticing in my developer window (F12) some spamming errors.
These were all the steps I did:
Open Visual Studio 2019
Create a project ASP.NET Core with React.js
Choose .Net Core 5.0
Left the option "Configure for HTTPS"
I pressed Play after the project finished loading
Clicked the F12 key and I noticed the errors popping up in the Console
I have gone through a lot of forums where people have posted about this issue but all of them have to do with people setting up their own "WebSocket Handlers". These people are actively working with web socket code. I haven't even learned web sockets yet. I found one website that remarked that I didn't have my script debugging enabled. So I did that but I still see the same error.
I notice in the error log that it points to WebSocketClient.js, line 16. But all that is located in ClientApp->node_modules and I have nothing to do with that directory or anything to do with those files.
My question is this: is the error happening because my visual studio project is not configured properly? If so, how do I fix my project in order to correct this issue? Many thanks in advance.
It's an issue with cra5 aka react-scripts v5:
To solve you need to add a .env file in the same folder where package.json is present.
In .env file put WDS_SOCKET_PORT=0, '0' means that it will dynamically pick whatever port on which local server is running.
Also need to add/uncomment the middleware UseReactDevelopmentServer in Startup.cs file. So it can be used as proxy to node dev server as v5 not using react-web-utils directly.
app.UseSpa(spa =>
{
spa.Options.SourcePath = "ClientApp";
if (env.IsDevelopment())
{
spa.UseReactDevelopmentServer(npmScript: "start");
}
});
just started working with reactjs recently, month or two..not a pro but can find my way around.. I am using create ract app (quickie ,that ships with service-worker) and my setup is such that I am deploying react app in the root of my java REST application, so all my service rest calls are in relative format, e.g /rest/myservice/123 etc.. and they work just fine..
but recently I started getting strange errors, and rest calls stopped working..
if I execute RET URL from browser .... nothing happens index loads... when I test with postman REST works just fine it also works in safari or if url is localhost... ...so after hours of frustration i discovered that service worker doing its .... caching . my rest calls are getting intercepted and they never make it to server... and there is nowhere that it mentions about how to overcome it, neither in service worker docs nor in create-react-app docs ...nothing is mentioned about this use case...... this is so pathetic...
I figured it out after numerous trail and errors... but it did not stop there..
I went ahead and deleted the service-worker registration entry from index.js also deleted service-worker file and rebuild the app. well service-worker.js file is still there... it showed up in build folder after I rebuild the project..... what is it with create-react-app did they got paid by google to include service-worker? or what is going on? why can not I remove it? and how do I prevent it from canceling my rest url calls?
when I type : https://xxxx.io/x/referal/refCode/3429878 it just loads application...
what else am I missing?
got the answer over #Redit needed to unregister worker...
details #:
https://www.reddit.com/r/reactjs/comments/8hovvb/removal_of_serviceworker_from_reactjs_app/
I am trying to follow the tutorial on creating a MEAN app on scotch.io.
I am using the WebStorm IDE and after completely following through I am stuck with a problem that seems to emerge from WebStorm. If I click on the "Open in Chrome"-Button in the IDE I am referred to:
localhost:63342/scotch_mean_tutorial/views/index.html
However, the actual port that I specified in my server.js is 8080 file:
// listen (start app with node server.js) ======================
app.listen(8080);
console.log("App listening on port 8080");
I have built a node API and it works when I go to:
http://localhost:8080/api/todos
However, clicking on the "Open in Chrome" through my WebStorm IDE uses a different port (i.e. 63342) and thus I am left with the following error:
GET http://localhost:63342/api/todos 404 (Not Found)
I am not sure how to resolve this? Any ideas?
You need to create a javascript debug run configuration with the correct URL (http://localhost:8080/api/todos) and use this configuration to open your URL in browser. Another option: specify this URL in Live Edit/Browser tab of node.js run configuration you use to run your server.js and tick 'after launch' checkbox to automatically start the browser with this URL on server start.
In Webstorm 9, you can configure the port for debugging apps. In Preferences:
Build, Execution, Deployment > Debugger > Built-in Server Port
I am quite puzzled by this behavior.
I have a Java AppEngine instance which makes an http call to a "settings.php" on another server. But I get the following error:
ERROR :
java.io.IOException: Could not fetch URL: http://<3rdpartywebsite>/settings.php
at com.google.appengine.api.urlfetch.URLFetchServiceImpl.convertApplicationException(URLFetchServiceImpl.java:138)
at com.google.appengine.api.urlfetch.URLFetchServiceImpl.fetch(URLFetchServiceImpl.java:45)
at com.google.appengine.api.urlfetch.URLFetchServiceImpl.fetch(URLFetchServiceImpl.java:30)
...
I have tried using URLFetchService and even a simple HttpURLConnection class. Even tried with a different User-Agent and other http headers, but to no avail.
What is baffling is that the same code and website works fine on Local Eclipse Dev environment, works via Browser (can see php text) AND works on the Compute Engine too! Only the Production App Engine throws the "could not fetch" error. Unfortunately this is not a transient error, it fails 10/10 times.
Any idea what could be going wrong or something that I can try?
Thanks, Asim
I'm trying to add grunt-connect-proxy to a project that uses the latest yeoman + angular generator.
But, when hitting the road that should be forwarded (e.g. 127.0.0.1:9000/api/v1), the server returns this error:
An error has occurred: {"code":"ECONNREFUSED","errno":"ECONNREFUSED","syscall":"connect"}
I used a modified Gruntfile: same as here as recommended.
How I'm a supposed to debug this? Has anyone had a similar issue lately with grunt-connect-proxy?
I'm also interested in similar solutions for proxing api calls for an angular webapp, if you have any that actually work.
Thank you for helping me out! Much appreciated!
Gruntfile is fine, the error is caused by your backend, i.e. localhost:3000 (probably Rails).
If it is Rails, it's a CORS problem. You need to allow rails to accept connection from grunt server. Add 'rack-cors' to your gemfile and configure it like this in your development.rb config file:
config.middleware.use Rack::Cors do
allow do
origins 'localhost:9000'
resource '*', :headers => :any, :methods => [:get, :post, :options, :delete]
end
end
Check this link for detailed setup, it helped me to get it working.
Working with Angular.js and Rails
I was running into this issue while trying to develop locally using AngularJS with a Laravel backend.
I was able to get the grunt-conenct-proxy example working using the before mentioned Rails example: Working with Angular.js and Rails, however when trying to connect locally to my laravel backend I would always get the ECONNREFUSED error.
The only real difference I could see was that the rails server was spinning up on 0.0.0.0. where as my apache server was running on localhost/127.0.0.1. After changing my config for my apache sever to run at 0.0.0.0 using:
php artisan serve --host 0.0.0.0
I was the able to connect to my backed without issue. If anyone could comment and explain how/why this works I would be very grateful.
Well, I finally got it to work somehow.
But frankly, I don't get it. It was definitely related to localhost not being the same as 127.0.0.1. How did it ended that way, I don't have a clue...
I'll share what I learned while doing this, as I found no real answer for debugging this staff out there on the web. Here is what I learned:
grunt has a --verbose option that may help you see what's going on
If grunt-connect-proxy is configured correctly you must see something like this at startup:
Running "configureProxies" task
Proxy created for: /api/v1 to localhost:8000
In my case, the grunt server was running on 127.0.0.1:9000, the second server on localhost:8000. I proxied requests made on api/v1 so grunt server --verbose would output something like this on every proxied request:
Proxied request: /api/v1/test -> http://localhost:8000/api/v1/test
{
"host": "127.0.0.1:9000",
"connection": "keep-alive",
"accept": "...",
"user-agent": "...",
"accept-encoding": "...",
"accept-language": "...",
"cookie": "..."
}
the whole point of using a proxy is to avoid any unnecessary CORS configuration on your second server
This is because once deployed your frontend and backend code will coexist on the same server (= the grunt server is only needed at dev time). I wanted to stress that point, because #Ulugbek answer may suggest that you need CORS to make grunt-connect-proxy work.
the ECONNREFUSED error happens when your second server is not responding
In my case, I discovered that http://127.0.0.1:8000/api/v1/test was not responding even if http://localhost:8000/api/v1/test was. So, I messed around with the /etc/hosts a bit and solved the problem by making sure both endpoints were responding accordingly.
The same error may happen to you if the second server is not listening to the proxied endpoint.