Connecting to http://:5222/webchat/jivelive.jsp doesn’t work. The connection hangs. Using 5223 does the same, but 9090 and 9091 work beautifully.
I’d like to not open up 9090 and 9091 to the world since that also opens the admin console. I’ve got a web conferencing solution running on this box as well, but it isn’t set to listen on any of these ports. Spark users have no trouble connecting to the server, but I’m trying to get fastpath up and running and this is causing an issue.
Any ideas? I’ve got to be missing something obvious here…
In thinking about this for a moment rather than just trying things, I realized that 5222 and 5223 are most likely for client chat programs, not http access. So I decided to try port 7443. That port works when using http (force download of some compiled file) but not https (404).
Is it set up to use plain old port 80 for serving the jivelive.jsp file, and if so can I change that? That port is in use by the other app on the same machine.
The webchat.war can be deployed into any application server. The application server (e.g. tomcat, resin, jetty, websephere, weblogic, etc.) is the one listening on a given port. The port is unrelated to the jivelive.jsp file. It is the server that is serving the JSP files on a given port. And as you said, ports 5222 and 5223 are not HTTP ports but ports used by XMPP clients. In summary, choose the application server of your choice, configure the port and deploy the webchat.war.
This puts me halfway there, and confirms what I was thinking with my reply. Now I need the help boost to get to the second part:
How do I configure Openfire’s built-in Jetty web server to listen on a port of my choosing? I have tried looking, but the only other thread about this went un-answered as well.
So there is no way, from withinthe built in Jetty web server, to allow access to the admin interface on one port and give access on another port only to the directory that jivelive.jsp is in?
Just trying to add a layer of security by not giving public access to the admin console (will be using the firewall to only allow access on a specific port).
After thinking about this, the work around for it would be to run your own instance of Apache Tomcat (6 I hear works great with FastPath), configured to listen to a different port, and deploy the webchat.war file there. This is the recommended method of deployment (http://www.igniterealtime.org/projects/openfire/plugins/webchat/readme.html). The Tomcat service can still run on the same computer as Openfire
So the Openfire server will have the Fastpath Service installed there (port 9090), remove the the Fastpath Webchat service, and move the Fastpath webchat service to be hosted in the Tomcat webapps folder(on a different port allowed by firewall).