Re: [nodejs] Running NodeJS and Tomcat Locally

[José F. Romaniello]

Use cors or jsonp.
Cors works only in few browsers. With Jsonp you can only get things
(no post,delete,update)

Another thing i will try is to put the two things behind a reverse
proxy (http-proxy from nodejitsu is great) and have the tomcat thing
in the root while the node in /myrestyadayada

2012/6/3, Sean McGowan <smcg...@gmail.com>:
> I'm running NodeJS locally, with a simple HTTP server on port 8124.
>
> I'm running my web application in Tomcat on port 8080.
>
> I want my web application to make REST calls to the Node server.
>
> Any idas how I get around the cross-port communication issue here?
>
> Thanks,
> Seán
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

--
Enviado desde mi dispositivo móvil

[José F. Romaniello]

He said "cross port" and i thougth he was trying to call a rest endpoint in his node app from the cliendside page served by tomcat. Cross port (this is Same Origin Policy) is a policy for BROWSERS not for server side Java running on tomcat.

El lunes, 4 de junio de 2012, nicolas escribió:

Hello Sean,

From what I understood, your tomcat acts as a client. Therefore you don't need JSONP or CORS. You can make direct calls to your node application using the HttpUrlConnection. Here is a StackOverflow question and its answers: http://stackoverflow.com/questions/1359689/how-to-send-http-request-in-java.

Then, if your webapp is expecting and/or responding JSON, you will need a library to serialize and deserialize it. I'm using Google GSON which do the job well: http://code.google.com/p/google-gson/.

Also, when doing a request, don't forget to put the request's header "Content-Type" to "application/json" :)

- Nicolas

On Sunday, June 3, 2012 1:40:36 PM UTC+2, Sean McGowan wrote:

I'm running NodeJS locally, with a simple HTTP server on port 8124.

I'm running my web application in Tomcat on port 8080.

I want my web application to make REST calls to the Node server.

Any idas how I get around the cross-port communication issue here?

Thanks,

Seán

[Angel Java Lopez]

Hi people!

Sean, you can combine the two answers, from Nicolas and Jose.

If your browser settings doesn't recognize different ports as same origin, you could use a proxy servlet at Tomcat.

Search google for "proxy servlet"

I found:

http://edwardstx.net/2010/06/http-proxy-servlet/ 

that describes a similar situation, and gives some links, one:

http://frank.spieleck.de/download/ProxyServlet.java 

Loosely related, but with more info about <servlet-mappin...>

http://stackoverflow.com/questions/132052/servlet-for-serving-static-content 

so you can configure your Tomcat accepting /myajaxapi/* all request internally serving the Node output, without browser notice. But the proxy servlet code could be tricky: it should manage the node.js response headers, and serve as is to the browser.

Maybe googleing "proxy servlet for ajax". I just found

http://www.jroller.com/ray/entry/http_proxy_servlet_for_ajax

Angel "Java" Lopez

http://ajlopez.wordpress.com

http://twitter.com/ajlopez

[José F. Romaniello]

+1

I like this thing Angel, is like my suggestion of using the http-proxy ( https://github.com/nodejitsu/node-http-proxy ) but you avoid having an extra process running and managing that. I dont know about the "http-proxy-servlet" but the node-http-proxy is very straightforward to set up, examples in the same page.

2012/6/4 Angel Java Lopez <ajlop...@gmail.com>

[Angel Java Lopez]

Ah! I forget to mention...

The OTHER approach is to use socket.io from client, instead of Ajax. There is a socket.io client for Javascript, and a socket.io module in Node.js. 

It's not complicated, IMO, so it could deserve a try. And it could be extended to consume different node servers from the same client.

I don't sure about security limitations of this approach: but AFAIK, socket.io revert to HTTP long polling if it cannot establish a connection using WebSockets or other protocol (I know that socket.io team is going to change the algorithm to select the protocol) Or you can explicitly declare to use http long polling.